Incorrect fast-path mapping for absolute-position object under relative-positioned anonymous block |
||
Issue description
This is the current code in PaintInvalidationState handling absolute-position under relative-position inline:
if (m_currentObject.isOutOfFlowPositioned() && !fixed) {
if (LayoutObject* container = m_currentObject.container()) {
if (container->isInFlowPositioned() && container->isLayoutInline())
m_paintOffset += toLayoutInline(container)->offsetForInFlowPositionedInline(toLayoutBox(m_currentObject));
}
}
In the case that the above code is assumed to handle, the absolute-position block's container is not the relative-position inline, but a relative-position anonymous block.
This will be fixed by paint invalidation tree walk in layout tree order. For now we should force slow mapping.
BTW, I think we should avoid saying DOM-order (like in PaintPropertyTreeBuilder), because layout tree is in different structure from the DOM tree in this case.
,
Apr 4 2016
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/bf7dc636b3ed84582375d2cebe613ffaf1c00794 commit bf7dc636b3ed84582375d2cebe613ffaf1c00794 Author: wangxianzhu <wangxianzhu@chromium.org> Date: Mon Apr 04 23:52:56 2016 Remove ForceHorriblySlowRectMapping Change paint invalidation tree walk to DOM-order instead of containing- block order for out-of-flow positioned objects so that we can track paint invalidation container and paint offset for them correctly without forcing slow mapping if possible. Move some cases to fast path: - Absolute-position objects (except the slow-path cases): track paint offset etc separately for them. See stacked objects for paint invalidation container tracking. - Stacked objects (including absolute-position objects): track paint invalidation container separately for them. Still use slow path for the following cases (conditions are in supportsCachedOffsets() and supportsCachedOffsetsForChildren()): - Absolute-position whose container is above the current paint invalidation container for stacked contents; - Fixed-position objects: normally its paint invalidation container is either the LayoutView or below its containing block, so slow- path is either not so slow, or fast-path is not feasible; - Multicolumn, SVGBlock, objects with reflection or filter. BUG= 591199 , 598094 Review URL: https://codereview.chromium.org/1833493003 Cr-Commit-Position: refs/heads/master@{#385056} [modify] https://crrev.com/bf7dc636b3ed84582375d2cebe613ffaf1c00794/third_party/WebKit/Source/core/layout/LayoutBlock.cpp [modify] https://crrev.com/bf7dc636b3ed84582375d2cebe613ffaf1c00794/third_party/WebKit/Source/core/layout/LayoutBlock.h [modify] https://crrev.com/bf7dc636b3ed84582375d2cebe613ffaf1c00794/third_party/WebKit/Source/core/layout/LayoutBoxModelObject.cpp [modify] https://crrev.com/bf7dc636b3ed84582375d2cebe613ffaf1c00794/third_party/WebKit/Source/core/layout/LayoutObject.cpp [modify] https://crrev.com/bf7dc636b3ed84582375d2cebe613ffaf1c00794/third_party/WebKit/Source/core/layout/LayoutObject.h [modify] https://crrev.com/bf7dc636b3ed84582375d2cebe613ffaf1c00794/third_party/WebKit/Source/core/layout/LayoutState.h [modify] https://crrev.com/bf7dc636b3ed84582375d2cebe613ffaf1c00794/third_party/WebKit/Source/core/layout/LayoutView.h [modify] https://crrev.com/bf7dc636b3ed84582375d2cebe613ffaf1c00794/third_party/WebKit/Source/core/layout/PaintInvalidationState.cpp [modify] https://crrev.com/bf7dc636b3ed84582375d2cebe613ffaf1c00794/third_party/WebKit/Source/core/layout/PaintInvalidationState.h [modify] https://crrev.com/bf7dc636b3ed84582375d2cebe613ffaf1c00794/third_party/WebKit/Source/core/layout/svg/LayoutSVGBlock.cpp [modify] https://crrev.com/bf7dc636b3ed84582375d2cebe613ffaf1c00794/third_party/WebKit/Source/core/layout/svg/LayoutSVGBlock.h [modify] https://crrev.com/bf7dc636b3ed84582375d2cebe613ffaf1c00794/third_party/WebKit/Source/core/layout/svg/LayoutSVGText.cpp [modify] https://crrev.com/bf7dc636b3ed84582375d2cebe613ffaf1c00794/third_party/WebKit/Source/core/paint/README.md
,
Apr 4 2016
|
||
►
Sign in to add a comment |
||
Comment 1 by wangxianzhu@chromium.org
, Mar 28 2016The code is correct. What I observed is actually for fast/block/positioning/positioned-child-inside-relative-positioned-anonymous-block.html: <span style="position:relative"> <div> <div style="position: absolute"></div> </div> </span> This case is different from absolute-position directly under relative-position inline.