Changeset 94695 in webkit


Ignore:
Timestamp:
Sep 7, 2011 11:59:55 AM (13 years ago)
Author:
robert@webkit.org
Message:

Elements with position:absolute don't move to correct position after images load
​https://bugs.webkit.org/show_bug.cgi?id=54611

Reviewed by Simon Fraser.

Source/WebCore:

Test: fast/block/positioning/absolute-layout-after-image-load.html

fast/block/positioning/positioned-float-layout-after-image-load.html

In the test the 'label' block is an absolutely positioned child of an inline flow. So during layout,
this RenderBlock::layoutPositionedObjects fails to dirty it for rendering because it requires
the parent to be a BlockFlow. The code to do this was introduced in ​http://trac.webkit.org/changeset/8284.
There doesn't seem to be a good reason for requiring a BlockFlow, so remove the check. Do the same
for positioned floats in RenderBlock::positionedFloatsNeedRelayout(), although currently layoutPositionedObjects()
takes care of it this at least ensures no regression in future.

Note: Although the issue is encountered only on first load without a fragment identifier, it
happens reliably when you include the fragment identifier in the url (#Footnote_1). This is so
because scrolling to the fragment always happens before the image has loaded, rendering the page
and clearing the initial dirty bits in the positioned element's renderer. When the image finally
loads in this scenario, the positioned element is otherwise clean and relies on the above code to get
re-rendered.

  • rendering/RenderBlock.cpp:

(WebCore::RenderBlock::layoutPositionedObjects): remove the check for r->parent()->isBlockFlow() when

deciding whether to mark children for layout

(WebCore::RenderBlock::positionedFloatsNeedRelayout): ditto

LayoutTests:

  • fast/block/positioning/absolute-layout-after-image-load-expected.txt: Added.
  • fast/block/positioning/absolute-layout-after-image-load.html: Added.
  • fast/block/positioning/resources/absolute-layout-after-image-load-2.html: Added.
  • fast/block/positioning/positioned-float-layout-after-image-load-expected.txt: Added.
  • fast/block/positioning/positioned-float-layout-after-image-load.html: Added.
  • fast/block/positioning/resources/positioned-float-layout-after-image-load-2.html: Added.
Location:
trunk
Files:
6 added
3 edited

Legend:

Unmodified
Added
Removed

  • trunk/LayoutTests/ChangeLog

    r94689 r94695  
     12011-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        * fast/block/positioning/positioned-float-layout-after-image-load-expected.txt: Added.
     12        * fast/block/positioning/positioned-float-layout-after-image-load.html: Added.
     13        * fast/block/positioning/resources/positioned-float-layout-after-image-load-2.html: Added.
     14
    1152011-09-07  Pavel Podivilov  <podivilov@chromium.org>
    216

  • trunk/Source/WebCore/ChangeLog

    r94694 r94695  
     12011-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              fast/block/positioning/positioned-float-layout-after-image-load.html
     10
     11        In the test the 'label' block is an absolutely positioned child of an inline flow. So during layout,
     12        this RenderBlock::layoutPositionedObjects fails to dirty it for rendering because it requires
     13        the parent to be a BlockFlow. The code to do this was introduced in http://trac.webkit.org/changeset/8284.
     14        There doesn't seem to be a good reason for requiring a BlockFlow, so remove the check. Do the same
     15        for positioned floats in RenderBlock::positionedFloatsNeedRelayout(), although currently layoutPositionedObjects()
     16        takes care of it this at least ensures no regression in future.
     17
     18        Note: Although the issue is encountered only on first load without a fragment identifier, it
     19        happens reliably when you include the fragment identifier in the url (#Footnote_1). This is so
     20        because scrolling to the fragment always happens before the image has loaded, rendering the page
     21        and clearing the initial dirty bits in the positioned element's renderer. When the image finally
     22        loads in this scenario, the positioned element is otherwise clean and relies on the above code to get
     23        re-rendered.
     24
     25        * rendering/RenderBlock.cpp:
     26        (WebCore::RenderBlock::layoutPositionedObjects): remove the check for r->parent()->isBlockFlow() when
     27                                                         deciding whether to mark children for layout
     28        (WebCore::RenderBlock::positionedFloatsNeedRelayout): ditto
     29
    1302011-09-07  Anna Cavender  <annacc@chromium.org>
    231

  • trunk/Source/WebCore/rendering/RenderBlock.cpp

    r94582 r94695  
    22172217            return true;
    22182218
    2219         if (positionedObject->style()->hasStaticBlockPosition(isHorizontalWritingMode()) && positionedObject->parent() != this && positionedObject->parent()->isBlockFlow())
     2219        if (positionedObject->style()->hasStaticBlockPosition(isHorizontalWritingMode()) && positionedObject->parent() != this)
    22202220            return true;
    22212221       
    … …  
    22452245        // objects that are positioned implicitly like this.  Such objects are rare, and so in typical DHTML menu usage (where everything is
    22462246        // 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))
    22482248            r->setChildNeedsLayout(true, false);
    22492249           
Note: See TracChangeset for help on using the changeset viewer.