Context Navigation

← Previous Period
Next Period →

Timeline

Jan 15, 2012:

11:33 PM Changeset in webkit [105036] by commit-queue@webkit.org

9 edits in trunk/Source

Add DeviceOrientationEvent.absolute
https://bugs.webkit.org/show_bug.cgi?id=51742

Patch by Xinchao He <xinchao.he@intel.com> on 2012-01-15
Reviewed by Darin Fisher.

This patch add the DeviceOrientationEvent.absolute to follow the
latest w3c device orientation event spec.
http://www.w3.org/TR/orientation-event/

Source/WebCore:

bindings/js/JSDeviceOrientationEventCustom.cpp:

(WebCore::JSDeviceOrientationEvent::absolute):
(WebCore::JSDeviceOrientationEvent::initDeviceOrientationEvent):

bindings/v8/custom/V8DeviceOrientationEventCustom.cpp:

(WebCore::V8DeviceOrientationEvent::absoluteAccessorGetter):
(WebCore::V8DeviceOrientationEvent::initDeviceOrientationEventCallback):

dom/DeviceOrientation.cpp:

(WebCore::DeviceOrientation::create):
(WebCore::DeviceOrientation::DeviceOrientation):
(WebCore::DeviceOrientation::absolute):
(WebCore::DeviceOrientation::canProvideAbsolute):

dom/DeviceOrientation.h:
dom/DeviceOrientationEvent.idl:

Source/WebKit/chromium:

public/WebDeviceOrientation.h:

(WebKit::WebDeviceOrientation::WebDeviceOrientation):
(WebKit::WebDeviceOrientation::canProvideAbsolute):
(WebKit::WebDeviceOrientation::absolute):

src/WebDeviceOrientation.cpp:

(WebKit::WebDeviceOrientation::WebDeviceOrientation):
(WebKit::WebDeviceOrientation::operator=):
(WebKit::WebDeviceOrientation::operator PassRefPtr<WebCore::DeviceOrientation>):

8:03 PM Changeset in webkit [105035] by fpizlo@apple.com

5 edits
1 add in trunk/Source/JavaScriptCore

The C calling convention logic in DFG::SpeculativeJIT should be available even
when not generating code for the DFG speculative path
https://bugs.webkit.org/show_bug.cgi?id=76355

Reviewed by Dan Bernstein.

Moved all of the logic for placing C call arguments into the right place (stack
or registers) into a new class, DFG::CCallHelpers. This class inherits from
AssemblyHelpers, another DFG grab-bag of helper functions. I could have moved
this code into AssemblyHelpers, but decided against it, because I wanted to
limit the number of methods each class in the JIT has. Hence now we have a
slightly odd organization of JIT classes in DFG: MacroAssembler (basic instruction
emission) <= AssemblyHelpers (some additional JS smarts) <= CCallHelpers
(understands calls to C functions) <= JITCompiler (can compile a graph to machine
code). Each of these except for JITCompiler can be reused for stub compilation.

GNUmakefile.list.am:
JavaScriptCore.xcodeproj/project.pbxproj:
dfg/DFGCCallHelpers.h: Added.

(JSC::DFG::CCallHelpers::CCallHelpers):
(JSC::DFG::CCallHelpers::resetCallArguments):
(JSC::DFG::CCallHelpers::addCallArgument):
(JSC::DFG::CCallHelpers::setupArguments):
(JSC::DFG::CCallHelpers::setupArgumentsExecState):
(JSC::DFG::CCallHelpers::setupArgumentsWithExecState):
(JSC::DFG::CCallHelpers::setupTwoStubArgs):
(JSC::DFG::CCallHelpers::setupStubArguments):

dfg/DFGJITCompiler.h:

(JSC::DFG::JITCompiler::JITCompiler):

dfg/DFGSpeculativeJIT.h:

(JSC::DFG::SpeculativeJIT::callOperation):

4:57 PM Changeset in webkit [105034] by kling@webkit.org

1 edit in trunk/Source/WebCore/ChangeLog

Fix wrong bug URL in ChangeLog.

3:18 PM Changeset in webkit [105033] by macpherson@chromium.org

5 edits in trunk/Source/WebCore

Remove external references to CSSPrimitiveValue::UnitTypes enum.
https://bugs.webkit.org/show_bug.cgi?id=76229

Reviewed by Darin Adler.

No new tests / refactoring only.

css/CSSFontSelector.cpp:

(WebCore::CSSFontSelector::addFontFaceRule):

css/CSSGradientValue.cpp:

(WebCore::CSSGradientValue::addStops):
(WebCore::positionFromValue):
(WebCore::CSSGradientValue::isCacheable):
(WebCore::CSSRadialGradientValue::resolveRadius):
(WebCore::CSSRadialGradientValue::createGradient):

css/CSSPrimitiveValue.h:

(WebCore::CSSPrimitiveValue::isUnitTypeLength):
(WebCore::CSSPrimitiveValue::isFontRelativeLength):
(WebCore::CSSPrimitiveValue::isIdent):
(WebCore::CSSPrimitiveValue::isNumber):
(WebCore::CSSPrimitiveValue::isPercentage):
(WebCore::CSSPrimitiveValue::isString):
(WebCore::CSSPrimitiveValue::isURI):

css/CSSStyleApplyProperty.cpp:

(WebCore::ApplyPropertyLength::applyValue):
(WebCore::ApplyPropertyBorderRadius::applyValue):
(WebCore::ApplyPropertyFontSize::applyValue):
(WebCore::ApplyPropertyCursor::applyValue):
(WebCore::ApplyPropertyPageSize::applyValue):
(WebCore::ApplyPropertyTextEmphasisStyle::applyValue):
(WebCore::ApplyPropertyZoom::applyValue):

3:08 PM BuildBot edited by gulendekorasyon@gmail.com

(diff)

3:07 PM WikiStart edited by gulendekorasyon@gmail.com

(diff)

3:06 PM UsingGitWithWebKit edited by gulendekorasyon@gmail.com

(diff)

3:02 PM WikiStart edited by gulendekorasyon@gmail.com

(diff)

12:14 PM Changeset in webkit [105032] by commit-queue@webkit.org

11 edits in trunk

Fix compilation errors on build-webkit --debug --no-video on mac.
https://bugs.webkit.org/show_bug.cgi?id=75867

Patch by Pablo Flouret <pablof@motorola.com> on 2012-01-15
Reviewed by Philippe Normand.

Source/JavaScriptCore:

Make ENABLE_VIDEO_TRACK conditional on ENABLE_VIDEO, video track feature
doesn't build without video.

wtf/Platform.h:

Source/WebCore:

Some exported HTMLMediaElement symbols were guarded by FULLSCREEN_API feature instead of VIDEO.
Unused parameter warning in CanvasRenderingContext::wouldTaintOrigin().
RenderThemeMac::shouldShowPlaceholderWhenFocused() implementation wrongly guarded by VIDEO feature.

WebCore.exp.in:
html/canvas/CanvasRenderingContext.cpp:

(WebCore::CanvasRenderingContext::wouldTaintOrigin):

rendering/RenderThemeMac.mm:

Source/WebKit/mac:

WebChromeClient::fullScreenRendererChanged() declaration wrongly guarded by VIDEO feature instead of FULLSCREEN_API.
_isAnyMoviePlaying implementation depends on VIDEO.

WebCoreSupport/WebChromeClient.h:
WebView/WebFullScreenController.mm:

(-[WebFullScreenController _isAnyMoviePlaying]):

Tools:

Add --[no-]video-track to build-webkit, since video track feature
depends on video.

Scripts/build-webkit:

11:42 AM Changeset in webkit [105031] by kling@webkit.org

2 edits in trunk/Source/WebCore

CSSParser: Fix failing assertion below BorderImageQuadParseContext.
<http://webkit.org/b/76343> and <rdar://problem/10584969>

Reviewed by Antti Koivisto.

No longer asserts: fast/borders/inline-mask-overlay-image-outset-vertical-rl.html

css/CSSParser.cpp:

(WebCore::BorderImageSliceParseContext::commitBorderImageSlice):
(WebCore::BorderImageQuadParseContext::commitBorderImageQuad):

Clone CSSValues by copying the RefPtrs instead of going through
the CSSValuePool's create-from-double factory. This prevents an
assertion when the incoming value is CSSValueAuto.

11:01 AM WikiStart edited by robert@roberthogan.net

(diff)

9:17 AM Changeset in webkit [105030] by robert@webkit.org

6 edits
2 adds in trunk

Reviewed by Eric Seidel.

Source/WebCore:

Test: fast/images/embed-does-not-propagate-dimensions-to-object-ancestor.html

WebKit seems to have inherited this behaviour from KHTML. When the width/height
of an <embed> element is set, it propagates the values up to any parent <object>
element. There doesn't seem to be any good reason for this and it is not consistent
with the behaviour of Firefox and Opera.

html/HTMLEmbedElement.cpp:

(WebCore::HTMLEmbedElement::insertedIntoDocument):
(WebCore::HTMLEmbedElement::attributeChanged): Removed

html/HTMLEmbedElement.h:

(WebCore::HTMLEmbedElement::attributeChanged): Removed

LayoutTests:

fast/dom/insertedIntoDocument-child-expected.txt:
fast/dom/insertedIntoDocument-sibling-expected.txt: These tests were added by http://trac.webkit.org/changeset/81611. The fact that an <embed> element inserted into the document no longer passes its height/width up to its parent object node seems to prevent the node getting removed by a simple garbage collection now so the <embed> added by the test is still there at the end, creating the trailing spaces. This is consistent with Opera's treatment of the test, FF is entirely different - it doesn't add the embed node in the first place. So given that the purpose of the test is to cause a crash (?), the change in result seems benign.
fast/images/embed-does-not-propagate-dimensions-to-object-ancestor-expected.txt: Added.
fast/images/embed-does-not-propagate-dimensions-to-object-ancestor.html: Added. This tests that the width/height for an embed element does not get propagated to the parent object.

6:20 AM WikiStart edited by gulendekorasyon@gmail.com

(diff)

5:48 AM Changeset in webkit [105029] by robert@webkit.org

5 edits in trunk/Source/WebCore

compareBorders() is called too often during painting
https://bugs.webkit.org/show_bug.cgi?id=73349

Reviewed by Julien Chaffraix.

Collapsed borders are re-calculated every time they are painted.
This is unnecessary, they only change with the layout or style so calculate and
cache them whenever the layout or style changes and use the cached values when
painting. The cache is stored in the table section so that the memory footprint
of a table is only increased when it has collapsing borders.

The gain in performance here consists of skipping collapsed border computation
during painting. The only path that incurs a small performance penalty is the
additional get/set on the cache when a collapsed border is computed. This penalty only applies
during style change, layout, or when the width of the table is calculated. The computed
border value is not stored in the cache when it has been calculated without its color
for borderHalfStart and co., so that code path is unaffected by this change.

No new tests, covered by existing collapsed border tests.

rendering/RenderTableCell.cpp:

(WebCore::RenderTableCell::willBeDestroyed): remove entries from collapsed border cache
(WebCore::RenderTableCell::collapsedStartBorder):

Compute, and also cache if the full border including color was computed.

(WebCore::RenderTableCell::computeCollapsedStartBorder):
(WebCore::RenderTableCell::collapsedEndBorder): ditto
(WebCore::RenderTableCell::computeCollapsedEndBorder):
(WebCore::RenderTableCell::collapsedBeforeBorder): ditto
(WebCore::RenderTableCell::computeCollapsedBeforeBorder):
(WebCore::RenderTableCell::collapsedAfterBorder): ditto
(WebCore::RenderTableCell::computeCollapsedAfterBorder):
(WebCore::RenderTableCell::cachedCollapsedLeftBorder):

Inline the function since it is only called in paintCollapsedBorders and remove
includeColor as a parameter. Move the call to the table's style to the caller rather
than call it 4 times in a row. Use the cached border values directly.

(WebCore::RenderTableCell::cachedCollapsedRightBorder): ditto
(WebCore::RenderTableCell::cachedCollapsedTopBorder): ditto
(WebCore::RenderTableCell::cachedCollapsedBottomBorder): ditto
(WebCore::RenderTableCell::paintCollapsedBorders):

This function always uses the collapsed border cache now.

rendering/RenderTableCell.h: Make the collapsed border functions private.
rendering/RenderTableSection.cpp:

(WebCore::RenderTableSection::removeCachedCollapsedBorders): The cache is deleted by the HashMap

since it is the only owner of the cached item.

(WebCore::RenderTableSection::setCachedCollapsedBorder):
(WebCore::RenderTableSection::cachedCollapsedBorder):

This will assert if there is no cached collapsed border for the side of the
cell requested by the caller.

rendering/RenderTableSection.h: HashMap wouldn't let me use CollapsedBorderSide in the key value for the cache so use int instead.

Jan 14, 2012:

7:14 PM Changeset in webkit [105028] by levin@chromium.org

8 edits
1 move in trunk/Source

HWndDC should be in platform/win instead of wtf.
https://bugs.webkit.org/show_bug.cgi?id=76314

Reviewed by Sam Weinig.

Source/JavaScriptCore:

JavaScriptCore.gyp/JavaScriptCore.gyp:
JavaScriptCore.gypi:

Source/WebCore:

No new functionality, so no new tests.

WebCore.gypi:
WebCore.vcproj/WebCore.vcproj:
platform/win/HWndDC.h: Renamed from Source/JavaScriptCore/wtf/win/HWndDCWin.h.

I also made the class non-copyable.
(WebCore::HWndDC::HWndDC):
(WebCore::HWndDC::~HWndDC):
(WebCore::HWndDC::operator HDC):

Source/WebKit/chromium:

src/win/WebScreenInfoFactory.cpp:

(WebKit::WebScreenInfoFactory::screenInfo):

5:24 PM Changeset in webkit [105027] by commit-queue@webkit.org

2 edits in trunk/Source/WebCore

https://bugs.webkit.org/show_bug.cgi?id=76339

Take a page from the Gtk and Qt ports and quiet these logs unless they
are explicitly enabled via environment variable.

Patch by Adam Treat <atreat@rim.com> on 2012-01-14
Reviewed by George Staikos.

platform/blackberry/LoggingBlackBerry.cpp:

(WebCore::initializeLoggingChannelsIfNecessary):

4:31 PM Changeset in webkit [105026] by mitz@apple.com

2 edits in trunk/Source/WebKit2

<rdar://problem/10696295> Crash in WebProcess at com.apple.CFNetwork: URLCredentialStorage::CreateCurrentPersistentCredentials + 298

Reviewed by Anders Carlsson.

WebProcess/mac/SecItemShimMethods.mm:

(WebKit::initializeSecItemShim): Removed an early return that was accidentally added in r105008.

3:53 PM Changeset in webkit [105025] by robert@webkit.org

1 edit
6 adds in trunk/LayoutTests

Chromium results for test added by r105021

Unreviewed gardening.

platform/chromium-linux/css2.1/20110323/outline-color-applies-to-008-expected.png: Added.
platform/chromium-mac-leopard/css2.1/20110323/outline-color-applies-to-008-expected.png: Added.
platform/chromium-mac-snowleopard/css2.1/20110323/outline-color-applies-to-008-expected.png: Added.
platform/chromium-mac-snowleopard/css2.1/20110323/outline-color-applies-to-008-expected.txt: Added.
platform/chromium-win/css2.1/20110323/outline-color-applies-to-008-expected.png: Added.
platform/chromium-win/css2.1/20110323/outline-color-applies-to-008-expected.txt: Added.

12:46 PM Changeset in webkit [105024] by robert@webkit.org

2 edits in trunk/LayoutTests

Change expected failures from IMAGE+TEXT to TEXT on Mac.

The Mac bots do not check pixel results so displays results suppressed
as IMAGE+TEXT as unexpected failures. Change the suppressions to TEXT.
These results require rebaseline since the changes landed in r103251.

Unreviewed gardening.

platform/mac/test_expectations.txt:

12:31 PM Changeset in webkit [105023] by robert@webkit.org

1 edit
1 delete in trunk/LayoutTests

Remove reference result added in r105021.

This reference result only works in chromium-linux and qt it seems,
so remove it and allow ports to add port-specific png results.

Unreviewed.

css2.1/20110323/outline-color-applies-to-008-expected.html: Removed.

11:28 AM Changeset in webkit [105022] by commit-queue@webkit.org

2 edits in trunk/Tools

[chromium] Failing webkit_unit_tests does not make the cr-linux EWS bubble red
https://bugs.webkit.org/show_bug.cgi?id=76313

Patch by James Robinson <jamesr@chromium.org> on 2012-01-14
Reviewed by Adam Barth.

The exit code of this script should be the exit code of webkit_unit_tests. Tested manually.

Scripts/run-chromium-webkit-unit-tests:

11:13 AM Changeset in webkit [105021] by robert@webkit.org

5 edits
30 adds in trunk

CSS 2.1 failure: outline-color-applies-to* tests fail
https://bugs.webkit.org/show_bug.cgi?id=71944

Reviewed by Julien Chaffraix.

Source/WebCore:

Paint the outline color for row, row-group, header-group and footer-group
elements.

Tests: css2.1/20110323/outline-color-applies-to-001.htm

css2.1/20110323/outline-color-applies-to-002.htm
css2.1/20110323/outline-color-applies-to-003.htm
css2.1/20110323/outline-color-applies-to-004.htm
css2.1/20110323/outline-color-applies-to-005.htm
css2.1/20110323/outline-color-applies-to-006.htm
css2.1/20110323/outline-color-applies-to-007.htm
css2.1/20110323/outline-color-applies-to-008.htm
css2.1/20110323/outline-color-applies-to-009.htm
css2.1/20110323/outline-color-applies-to-010.htm
(There is no outline-color-applies-to-011.htm in the test suite.)
css2.1/20110323/outline-color-applies-to-012.htm
css2.1/20110323/outline-color-applies-to-013.htm
css2.1/20110323/outline-color-applies-to-014.htm
css2.1/20110323/outline-color-applies-to-015.htm
fast/css/outline-color-self-painting-row.htm

rendering/RenderTableRow.cpp:

(WebCore::RenderTableRow::paintOutlineForRowIfNeeded): Wrapper function for painting the outline for the row.

This is used by RenderTableSection::paintObject and RenderTableRow::paint

(WebCore::RenderTableRow::paint): For rows with a self-painting layer, paint the outline. Tested by

fast/css/outline-color-self-painting-row.htm.

rendering/RenderTableSection.cpp:

(WebCore::RenderTableSection::paint): Paint the outline for header-group, row-group and footer-groups.
(WebCore::RenderTableSection::paintObject): When iterating through the cells paint the outline of rows as required.
Doing it here avoids the need to walk the RenderTableSection's tree separately elsewhere.

LayoutTests:

css2.1/20110323/outline-color-applies-to-001-expected.html: Added.
css2.1/20110323/outline-color-applies-to-001.htm: Added.
css2.1/20110323/outline-color-applies-to-002-expected.html: Added.
css2.1/20110323/outline-color-applies-to-002.htm: Added.
css2.1/20110323/outline-color-applies-to-003-expected.html: Added.
css2.1/20110323/outline-color-applies-to-003.htm: Added.
css2.1/20110323/outline-color-applies-to-004-expected.html: Added.
css2.1/20110323/outline-color-applies-to-004.htm: Added.
css2.1/20110323/outline-color-applies-to-005-expected.html: Added.
css2.1/20110323/outline-color-applies-to-005.htm: Added.
css2.1/20110323/outline-color-applies-to-006-expected.html: Added.
css2.1/20110323/outline-color-applies-to-006.htm: Added.
css2.1/20110323/outline-color-applies-to-007-expected.html: Added.
css2.1/20110323/outline-color-applies-to-007.htm: Added.
css2.1/20110323/outline-color-applies-to-008-expected.html: Added.
css2.1/20110323/outline-color-applies-to-008.htm: Added.
css2.1/20110323/outline-color-applies-to-009-expected.html: Added.
css2.1/20110323/outline-color-applies-to-009.htm: Added.
css2.1/20110323/outline-color-applies-to-010-expected.html: Added.
css2.1/20110323/outline-color-applies-to-010.htm: Added.
css2.1/20110323/outline-color-applies-to-012-expected.html: Added.
css2.1/20110323/outline-color-applies-to-012.htm: Added.
css2.1/20110323/outline-color-applies-to-013-expected.html: Added.
css2.1/20110323/outline-color-applies-to-013.htm: Added.
css2.1/20110323/outline-color-applies-to-014-expected.html: Added.
css2.1/20110323/outline-color-applies-to-014.htm: Added.
css2.1/20110323/outline-color-applies-to-015-expected.html: Added.
css2.1/20110323/outline-color-applies-to-015.htm: Added.
fast/css/outline-color-self-painting-row-expected.html: Added.
fast/css/outline-color-self-painting-row.htm: Added.

11:11 AM Changeset in webkit [105020] by dslomov@google.com

2 edits
1 delete in trunk/Source/WebKit/chromium

[Chromium] Remove WebKit::WebWorker class.
https://bugs.webkit.org/show_bug.cgi?id=76327

Reviewed by Darin Fisher.

public/WebWorker.h: Removed.
src/WebWorkerClientImpl.cpp:

7:51 AM Changeset in webkit [105019] by Simon Fraser

3 edits
2 adds in trunk

Unmatched transparency layer begin/end on a filtered element with an opacity ancestor
https://bugs.webkit.org/show_bug.cgi?id=76329

Source/WebCore:

Reviewed by Dan Bernstein.

When doing a paint with painting disabled on the GraphicsContext, as we do
for updating control tints, or computing text rectangles on Find, do not
apply filter effects. This is both a performance gain, and fixes an issue
with mismatched begin/end transparency layers.