Changeset 94785 in webkit
- Timestamp:
- Sep 8, 2011 12:58:32 PM (13 years ago)
- Location:
- trunk
- Files:
-
- 3 added
- 4 edited
Legend:
- Unmodified
- Added
- Removed
-
trunk/LayoutTests/ChangeLog
r94784 r94785 1 2011-09-03 Robert Hogan <robert@webkit.org> 2 3 Elements with position:absolute don't move to correct position after images load 4 https://bugs.webkit.org/show_bug.cgi?id=54611 5 6 Reviewed by Simon Fraser. 7 8 * fast/block/positioning/absolute-layout-after-image-load-expected.txt: Added. 9 * fast/block/positioning/absolute-layout-after-image-load.html: Added. 10 * fast/block/positioning/resources/absolute-layout-after-image-load-2.html: Added. 11 1 12 2011-09-08 Roland Steiner <rolandsteiner@chromium.org> 2 13 -
trunk/LayoutTests/platform/chromium/test_expectations.txt
r94782 r94785 3715 3715 BUG_REED : fast/canvas/quadraticCurveTo.xml = IMAGE 3716 3716 BUG_REED : fast/canvas/canvas-lineWidth.html = TEXT 3717 3718 BUGWK67769 DEBUG : fast/block/positioning/positioned-float-layout-after-image-load.html = CRASH -
trunk/Source/WebCore/ChangeLog
r94784 r94785 1 2011-09-03 Robert Hogan <robert@webkit.org> 2 3 Elements with position:absolute don't move to correct position after images load 4 https://bugs.webkit.org/show_bug.cgi?id=54611 5 6 Reviewed by Simon Fraser. 7 8 Test: fast/block/positioning/absolute-layout-after-image-load.html 9 10 In the test the 'label' block is an absolutely positioned child of an inline flow. So during layout, 11 this RenderBlock::layoutPositionedObjects fails to dirty it for rendering because it requires 12 the parent to be a BlockFlow. The code to do this was introduced in http://trac.webkit.org/changeset/8284. 13 There doesn't seem to be a good reason for requiring a BlockFlow, so remove the check. 14 15 Note: Although the issue is encountered only on first load without a fragment identifier, it 16 happens reliably when you include the fragment identifier in the url (#Footnote_1). This is so 17 because scrolling to the fragment always happens before the image has loaded, rendering the page 18 and clearing the initial dirty bits in the positioned element's renderer. When the image finally 19 loads in this scenario, the positioned element is otherwise clean and relies on the above code to get 20 re-rendered. 21 22 Note: This was originally landed in r94755 but positioned-float-layout-after-image-load.html exposed 23 an ASSERT bug, unrelated to this change, and was rolled out. That issue is tracked separately 24 in bug 67759. 25 26 * rendering/RenderBlock.cpp: 27 (WebCore::RenderBlock::layoutPositionedObjects): remove the check for r->parent()->isBlockFlow() when 28 deciding whether to mark children for layout 29 1 30 2011-09-08 Roland Steiner <rolandsteiner@chromium.org> 2 31 -
trunk/Source/WebCore/rendering/RenderBlock.cpp
r94755 r94785 2245 2245 // objects that are positioned implicitly like this. Such objects are rare, and so in typical DHTML menu usage (where everything is 2246 2246 // positioned explicitly) this should not incur a performance penalty. 2247 if (relayoutChildren || (r->style()->hasStaticBlockPosition(isHorizontalWritingMode()) && r->parent() != this && r->parent()->isBlockFlow()))2247 if (relayoutChildren || (r->style()->hasStaticBlockPosition(isHorizontalWritingMode()) && r->parent() != this)) 2248 2248 r->setChildNeedsLayout(true, false); 2249 2249
Note: See TracChangeset
for help on using the changeset viewer.