Context Navigation

← Previous Period
Next Period →

Timeline

Jun 16, 2013:

11:53 PM Changeset in webkit [151630] by commit-queue@webkit.org

3 edits
1 add in trunk/LayoutTests

[CSS Blending] Update the background-blend-mode-image-color-dynamic test to use the repaint test logic

Updating testcase verifying if background blend modes are updated dynamically from script. This now
properly uses the repaint test mechanism. Also, the background image resource is addded.

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

Patch by Mihai Tica <mitica@adobe.com> on 2013-06-16
Reviewed by Dean Jackson.

fast/repaint/background-blend-mode-image-color-dynamic-expected.html:
fast/repaint/background-blend-mode-image-color-dynamic.html:
fast/repaint/resources/ducky.png: Added.

11:28 PM WebKitIDL edited by Christophe Dumez

Fix several index links (diff)

9:23 PM Changeset in webkit [151629] by Simon Fraser

2 edits in trunk/Source/WebCore

Fix test assertion after r151624

An assertion was hit in RenderObject::willBeDestroyed()
for fast/css/getComputedStyle/getComputedStyle-background-shorthand.html
because the code asserted that the RenderObject had been removed from
the FrameView's slowRepaintObject set before remove() was called,
so move the assertion to after that call.

rendering/RenderObject.cpp:

(WebCore::RenderObject::willBeDestroyed):

8:56 PM Changeset in webkit [151628] by gyuyoung.kim@samsung.com

2 edits in trunk/Source/WebCore

Remove a redundant virtual call to hostWindow() in FrameView::invalidateRect()
https://bugs.webkit.org/show_bug.cgi?id=117685

Reviewed by Andreas Kling.

From Blink r152490 by <vivek.vg@samsung.com>

page/FrameView.cpp:

(WebCore::FrameView::invalidateRect): Avoid hostWindow() twice call.

7:25 PM Changeset in webkit [151627] by tkent@chromium.org

5 edits
2 adds in trunk

Fix two assertion failures in Range::insertNode
https://bugs.webkit.org/show_bug.cgi?id=116511

Reviewed by Ryosuke Niwa.

Source/WebCore:

ASSERTION FAILED: childBefore == (offset ? container->childNode(offset - 1) : 0)
third_party/WebKit/Source/WebCore/dom/RangeBoundaryPoint.h(115) : void WebCore::RangeBoundaryPoint::set(PassRefPtr<WebCore::Node>, int, WebCore::Node *)

ASSERTION FAILED: child->parentNode()
../../third_party/WebKit/Source/core/dom/RangeBoundaryPoint.h(133) : void WebCore::RangeBoundaryPoint::setToBeforeChild(WebCore::Node *)

1 0x87594b2 WebCore::RangeBoundaryPoint::setToBeforeChild(WebCore::Node*)
2 0x87534a9 WebCore::Range::insertNode(WTF::PassRefPtr<WebCore::Node>, int&)

Range::insertNode calls Node::insertBefore, in which an event handler
can update the DOM structure so that RangeBoundaryPoint don't like. We
postpone event dispatching by EventQueueScope.

Also, remove old comments about Acid3. The behavior is standardized.
(Step 9 of http://dom.spec.whatwg.org/#dom-range-insertnode)

This patch imports http://src.chromium.org/viewvc/blink?view=revision&revision=150470 .

Test: fast/dom/Range/range-insertNode-assertion.html

dom/Range.cpp:

(WebCore::Range::insertNode):

Add EventQueueScope
Remove obsolete comments

LayoutTests:

We need to update fast/dom/insertBefore-refChild-crash.html because the
test caused recursive calls to the event handler. container.innerHTML=
did nothing before this CL. Now container has the newChild because
DOMNodeRemoved event dispatching is delayed until Range::insertNode
completion.

We need to update fast/text/split-text-crash.xhtml so that it doesn't
stop when the event handler is called twice. I'm not sure why the test
worked before this CL.

fast/dom/Range/range-insertNode-assertion-expected.txt: Added.
fast/dom/Range/range-insertNode-assertion.html: Added.
fast/dom/insertBefore-refChild-crash.html:
fast/text/split-text-crash.xhtml:

6:58 PM Changeset in webkit [151626] by gyuyoung.kim@samsung.com

2 edits
10 adds in trunk/LayoutTests

Unreviewed. Added new baselines for some of editing/style tests, which works on EFL port.

platform/efl/TestExpectations:
platform/efl/editing/style/5017613-1-expected.png: Added.
platform/efl/editing/style/5017613-1-expected.txt: Added.
platform/efl/editing/style/5046875-1-expected.png: Added.
platform/efl/editing/style/5046875-1-expected.txt: Added.
platform/efl/editing/style/5065910-expected.png: Added.
platform/efl/editing/style/5065910-expected.txt: Added.
platform/efl/editing/style/5228141-expected.png: Added.
platform/efl/editing/style/5228141-expected.txt: Added.
platform/efl/editing/style/5279521-expected.png: Added.
platform/efl/editing/style/5279521-expected.txt: Added.

6:13 PM Changeset in webkit [151625] by gyuyoung.kim@samsung.com

2 edits
18 adds in trunk/LayoutTests

Unreviewed. Added new baselines for some of editing/selection tests as r151533 on EFL port.

platform/efl/TestExpectations:

4:32 PM Changeset in webkit [151624] by Simon Fraser

5 edits
2 adds in trunk

Fixed backgrounds in composited layers not repainted on scrolling
https://bugs.webkit.org/show_bug.cgi?id=117684

Source/WebCore:

Reviewed by Tim Horton.

FrameView is aware that "slow-repaint objects" (i.e. renderers with
background-attachment:fixed) require a slow-scrolling path. However,
it was ignorant of the fact that such objects could be painting into
compositing layers; it simply dirtied the main tiles, and nothing else.

Fix by having FrameView track the slow-repaints objects explicitly, as we
do for position:fixed, and repaint each of them on scrolling.

Test: compositing/repaint/fixed-background-scroll.html

page/FrameView.cpp:

(WebCore::FrameView::FrameView): No need to initialize m_slowRepaintObjectCount,
which is now an OwnPtr<RenderObjectSet>.
(WebCore::FrameView::useSlowRepaints): Use hasSlowRepaintObjects() now.
(WebCore::FrameView::addSlowRepaintObject): Now adds the object to a set,
allocating the set if necessary.
(WebCore::FrameView::removeSlowRepaintObject): Remove the object from the set,
and deallocate the set if empty.
(WebCore::FrameView::scrollContentsSlowPath): Call repaintSlowRepaintObjects();
this is the change that fixes the bug for always-composited implementations (e.g.
tile cache). This is a conservative change; we still invalidate the tile cache
as well. This could be optimized later.
(WebCore::FrameView::repaintSlowRepaintObjects): Repaint each object in the set.
Their appropriate compositing ancestor will be repainted.
(WebCore::FrameView::scrollPositionChangedViaPlatformWidget): Call
repaintSlowRepaintObjects() so that fixed backgrounds in composited layers are
correctly repainted; this fixes the bug for WebKit1.

page/FrameView.h: Replace m_slowRepaintObjectCount with a HashSet of

RenderObjects.
(WebCore::FrameView::hasSlowRepaintObject): Takes a RenderObject* now.
(WebCore::FrameView::hasSlowRepaintObjects): Ditto.

rendering/RenderObject.cpp:

(WebCore::RenderObject::styleWillChange): Pass the RenderObject.
(WebCore::RenderObject::willBeDestroyed): Assert that this RenderObject
has been removed from FrameView's set of slow-repaint objects already, if
the document is not being destroyed.
(WebCore::RenderObject::willBeRemovedFromTree): Pass the RenderObject.

LayoutTests:

Reviewed by Tim Horton.

Test that verifies that a composited layer with a fixed background is repainted
on scrolling.

compositing/repaint/fixed-background-scroll-expected.txt: Added.
compositing/repaint/fixed-background-scroll.html: Added.

10:24 AM Changeset in webkit [151623] by Simon Fraser

8 edits
5 adds in trunk

Source/WebCore: Painting of fixed background images is wrong in composited layers
https://bugs.webkit.org/show_bug.cgi?id=65793

Reviewed by Sam Weinig.

The code that computed background image geometry for background-attachment:fixed
images was unaware of compositing, so often painting the image at the wrong location.

Fix by having RenderBoxModelObject::calculateBackgroundImageGeometry() do the correct
math for fixed backgrounds in composited layer by offsetting the viewport rect by
the paint container's absolute position.

Tests: compositing/backgrounds/fixed-background-on-descendant.html

compositing/backgrounds/fixed-backgrounds.html

rendering/RenderBox.cpp:

(WebCore::RenderBox::getBackgroundPaintedExtent): Now returns a bool indicating
whether it is returning a reliable extent rect. It can return false in the case where
a background is fixed, since computing the correct extent would require finding
the appropriate composited ancestor to pass to calculateBackgroundImageGeometry().
This is OK since this function is used for "background opaque" optimizations.
(WebCore::RenderBox::computeBackgroundIsKnownToBeObscured): If getBackgroundPaintedExtent()
returns false, return false.
(WebCore::RenderBox::maskClipRect): We removed mask-attachment, so we never need to
compute the composited ancestor here and can pass null.
(WebCore::RenderBox::repaintLayerRectsForImage): Unwrap a comment.
If the changed image is related to a fixed background, geometry.hasNonLocalGeometry()
will be true. In that cause, just repaint the entire renderer rather than groveling
around for a composited ancestor.

rendering/RenderBox.h: Changed name and signature of backgroundPaintedExtent.
rendering/RenderBoxModelObject.cpp:

(WebCore::RenderBoxModelObject::paintFillLayerExtended): calculateBackgroundImageGeometry()
now needs to know the painting container.
(WebCore::RenderBoxModelObject::calculateBackgroundImageGeometry): Now takes a painting
container, that is required to correctly compute the viewport-relative offset for fixed
backgrounds. geometry.setHasNonLocalGeometry() is set for fixed backgrounds to indicate
to callers that, if they didn't pass a paint container, the destRect is not accurate.
The main bug fix is also here: we move the viewportRect by the absolute location of
paint container, which is equivalent to the composited layer offset.
(WebCore::RenderBoxModelObject::getGeometryForBackgroundImage): calculateBackgroundImageGeometry()
takes a paint container.

rendering/RenderBoxModelObject.h:

(WebCore::RenderBoxModelObject::BackgroundImageGeometry::BackgroundImageGeometry):
(WebCore::RenderBoxModelObject::BackgroundImageGeometry::setHasNonLocalGeometry):
(WebCore::RenderBoxModelObject::BackgroundImageGeometry::hasNonLocalGeometry):

rendering/RenderImage.cpp:

(WebCore::RenderImage::computeBackgroundIsKnownToBeObscured): If getBackgroundPaintedExtent()
can't cheaply give an accurate answer, return false.

rendering/RenderLayerBacking.cpp:

(WebCore::RenderLayerBacking::updateDirectlyCompositedBackgroundImage): Pass the paint container,
which is our own renderer.

LayoutTests: Fixed background images behave strangely with webkit transitions
https://bugs.webkit.org/show_bug.cgi?id=65793

Reviewed by Sam Weinig.

Ref tests that compare fixed background rendering after a scroll, with and
without compositing, with a couple of layer configurations.

compositing/backgrounds/fixed-background-on-descendant-expected.html: Added.
compositing/backgrounds/fixed-background-on-descendant.html: Added.
compositing/backgrounds/fixed-backgrounds-expected.html: Added.
compositing/backgrounds/fixed-backgrounds.html: Added.

9:57 AM Changeset in webkit [151622] by Simon Fraser

7 edits
2 adds in trunk

webkit-backface-visibility on a parent element stops background-position from updating
https://bugs.webkit.org/show_bug.cgi?id=116319

Source/WebCore:

Reviewed by Darin Adler.

The optimization added in r102952 was incorrect in the case where a style change
resulted in a positioned-movement-only layout but also required a repaint; it assumed
that a composited layer did not need to be repainted for a a positioned-movement-only layout.

Fix by making RenderObject::setNeedsLayoutForPositionedMovement() check whether the
style change requires a repaint, and calling setLayerNeedsFullRepaint() in that situation.

Test: compositing/repaint/positioned-movement.html

rendering/RenderLayer.h: RepaintStatus values do not need to be bit flags.
rendering/RenderObject.cpp:

(WebCore::RenderObject::setStyle): Pass the old style to setNeedsPositionedMovementLayout().
(WebCore::RenderObject::styleDidChange): Ditto.

rendering/RenderObject.h:

(WebCore::RenderObject::setNeedsPositionedMovementLayout): Now takes a const RenderStyle*.

rendering/style/RenderStyle.cpp:

(WebCore::RenderStyle::diff): Remove a comment now that this bug is fixed.
(WebCore::RenderStyle::diffRequiresRepaint): Public wrapper for changeRequiresRepaint().
That function never uses contextSensitiveProperties so we can safely ignore them.

rendering/style/RenderStyle.h: Expose a way to call changeRequiresRepaint().

LayoutTests:

Reviewed by Darin Adler.

Test that does a positioned-movement-only layout and dumps a layer tree with
repaint rects.

compositing/repaint/positioned-movement-expected.txt: Added.
compositing/repaint/positioned-movement.html: Added.

8:06 AM Changeset in webkit [151621] by Darin Adler

2 edits in trunk/Source/WebCore

Try to fix iOS after last Pasteboard change.

platform/ios/PasteboardIOS.mm: (WebCore::Pasteboard::writeSelection): Put the new code inline here because the stringSelectionForPasteboard function is currently Mac-only.

Jun 15, 2013:

7:21 PM Changeset in webkit [151620] by Darin Adler

6 edits in trunk/Source/WebCore

Move Pasteboard::getStringSelection to Editor, fixing a layering violation
https://bugs.webkit.org/show_bug.cgi?id=117673

Reviewed by Ryosuke Niwa.

editing/Editor.h: Added stringSelectionForPasteboardWithImageAltText.

editing/mac/EditorMac.mm:

(WebCore::Editor::stringSelectionForPasteboard): Moved code here from the Pasteboard
class, since all the Pasteboard class did really was turn around and call back here.
(WebCore::Editor::stringSelectionForPasteboardWithImageAltText): Added. Variant of
the function above that includes image alt text. Separate named functions are often
the best pattern for something like this unless there are many different combinations.

platform/Pasteboard.h: Remove the Mac-only Pasteboard::getStringSelectioon.

platform/ios/PasteboardIOS.mm:

(WebCore::Pasteboard::writeSelection):

platform/mac/PasteboardMac.mm:

(WebCore::Pasteboard::writeSelectionForTypes):
Call the two new functions instead of the old Pasteboard::getStringSelection.

7:15 PM Changeset in webkit [151619] by Darin Adler

3 edits in trunk/Source/WebCore

Support using clang instead of gcc for bindings preprocessing
https://bugs.webkit.org/show_bug.cgi?id=117674

Reviewed by Sam Weinig.

I couldn't build on my computer because I don't have gcc installed.
This is my cut at fixing it.

bindings/scripts/CodeGeneratorObjC.pm:

(ReadPublicInterfaces): Use clang if present.

bindings/scripts/preprocessor.pm:

(applyPreprocessor): Ditto.

6:49 PM Changeset in webkit [151618] by fpizlo@apple.com

8 edits in branches/dfgFourthTier/Source

Concurrent JIT shouldn't try to recompute the CodeBlockHash as part of debug dumps, since doing so may fail if dealing with a CachedScript that doesn't have its script string handy
https://bugs.webkit.org/show_bug.cgi?id=117676

Reviewed by Sam Weinig.

Source/JavaScriptCore:

CodeBlock now caches m_hash, and the DFG Driver will force its computation if we're doing debug dumps of any kind.

Also made sure that CodeBlock::CodeBlock initializes all of its fields; it was previously missing the
initialization of m_capabilityLevelState.

bytecode/CodeBlock.cpp:

(JSC::CodeBlock::hash):
(JSC::CodeBlock::CodeBlock):

bytecode/CodeBlock.h:

(CodeBlock):

bytecode/CodeBlockHash.cpp:

(JSC::CodeBlockHash::CodeBlockHash):

bytecode/CodeBlockHash.h:

(CodeBlockHash):
(JSC::CodeBlockHash::isSet):
(JSC::CodeBlockHash::operator!):

dfg/DFGDriver.cpp:

(JSC::DFG::compile):

Source/WebCore:

Remove the broken hack for the concurrent JIT, since now the concurrent JIT won't use this code anymore.

No new tests because no new behavior.

loader/cache/CachedScript.cpp:

(WebCore::CachedScript::script):

3:56 PM Changeset in webkit [151617] by dino@apple.com

2 edits in trunk/Source/WebKit2

Crash in supportsSnapshotting
https://bugs.webkit.org/show_bug.cgi?id=117670
<rdar://problem/14059711>

Reviewed by Darin Adler.

Speculative fix for deferencing a null RefPtr in supportsSnapshotting.
It seems like it was possible to get in a state where the plugin machinery
would fire up and attempt to get a screenshot before there was an active
connection to the plugin process (usually under periods of high load, such
as opening a lot of tabs at once). In this case we're now returning false
from supportsSnapshotting, which will trigger the plugin to restart, but
that's better than requesting a snapshot on something that doesn't yet exist.

WebProcess/Plugins/PluginProxy.cpp:

(WebKit::PluginProxy::supportsSnapshotting): Guard for an empty connection object.

3:37 PM Changeset in webkit [151616] by fpizlo@apple.com

26 edits in branches/dfgFourthTier/Source/JavaScriptCore

fourthTier: DFG should support op_switch_imm
https://bugs.webkit.org/show_bug.cgi?id=117559

Reviewed by Oliver Hunt.

Implement integer (i.e. immediate) switches in the DFG. Reduce the minimum
threshold for using op_switch.

Also get rid of edge code support, since we haven't used it in the year since
I introduced it. It was supposed to allow us to break critical edges late in
the backend, thus enabling global register allocation from an SSA-form graph.
But we aren't doing that so I figure we should just kill the code for now. It
would have made implementing switch harder.

assembler/AbstractMacroAssembler.h:

(JSC::AbstractMacroAssembler::timesPtr):

assembler/MacroAssemblerCodeRef.h:

(JSC::MacroAssemblerCodePtr::dumpWithName):
(MacroAssemblerCodePtr):
(JSC::MacroAssemblerCodePtr::dump):
(MacroAssemblerCodeRef):
(JSC::MacroAssemblerCodeRef::dump):

bytecode/CodeBlock.cpp:

(JSC::CodeBlock::shrinkToFit):

bytecode/JumpTable.h:

(SimpleJumpTable):
(JSC::SimpleJumpTable::clear):

dfg/DFGAbstractState.cpp:

(JSC::DFG::AbstractState::executeEffects):
(JSC::DFG::AbstractState::mergeToSuccessors):

dfg/DFGBackwardsPropagationPhase.cpp:

(JSC::DFG::BackwardsPropagationPhase::propagate):

dfg/DFGByteCodeParser.cpp:

(InlineStackEntry):
(JSC::DFG::ByteCodeParser::parseBlock):
(JSC::DFG::ByteCodeParser::linkBlock):
(JSC::DFG::ByteCodeParser::InlineStackEntry::InlineStackEntry):

dfg/DFGCapabilities.cpp:

(JSC::DFG::capabilityLevel):

dfg/DFGCommon.h:
dfg/DFGFixupPhase.cpp:

(JSC::DFG::FixupPhase::fixupNode):

dfg/DFGGraph.cpp:

(JSC::DFG::Graph::dump):
(JSC::DFG::Graph::determineReachability):

dfg/DFGGraph.h:

(Graph):

dfg/DFGJITCompiler.cpp:

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

dfg/DFGJITCompiler.h:

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

dfg/DFGNode.h:

(DFG):
(JSC::DFG::SwitchCase::SwitchCase):
(SwitchCase):
(SwitchData):
(JSC::DFG::SwitchData::SwitchData):
(Node):
(JSC::DFG::Node::isSwitch):
(JSC::DFG::Node::isTerminal):
(JSC::DFG::Node::switchData):
(JSC::DFG::Node::numSuccessors):
(JSC::DFG::Node::successor):

dfg/DFGNodeType.h:

(DFG):

dfg/DFGOperations.cpp:
dfg/DFGOperations.h:
dfg/DFGPredictionPropagationPhase.cpp:

(JSC::DFG::PredictionPropagationPhase::propagate):

dfg/DFGSpeculativeJIT.cpp:

(JSC::DFG::SpeculativeJIT::SpeculativeJIT):
(JSC::DFG::SpeculativeJIT::compile):
(JSC::DFG::SpeculativeJIT::createOSREntries):
(JSC::DFG::SpeculativeJIT::emitSwitchImmIntJump):
(DFG):
(JSC::DFG::SpeculativeJIT::emitSwitchImm):
(JSC::DFG::SpeculativeJIT::emitSwitch):
(JSC::DFG::SpeculativeJIT::linkBranches):

dfg/DFGSpeculativeJIT.h:

(JSC::DFG::SpeculativeJIT::callOperation):
(SpeculativeJIT):
(JSC::DFG::SpeculativeJIT::branchDouble):
(JSC::DFG::SpeculativeJIT::branchDoubleNonZero):
(JSC::DFG::SpeculativeJIT::branch32):
(JSC::DFG::SpeculativeJIT::branchTest32):
(JSC::DFG::SpeculativeJIT::branch64):
(JSC::DFG::SpeculativeJIT::branchPtr):
(JSC::DFG::SpeculativeJIT::branchTestPtr):
(JSC::DFG::SpeculativeJIT::branchTest8):
(JSC::DFG::SpeculativeJIT::jump):