Paint property state may be incorrect for floating objects and columns spans |
||
Issue descriptionFloating objects and column spans escape paint effects of non-containing block ancestors. For now we only try to escape paint offset effect of non-containing block ancestors for them, having the following issues: (Removed 4/1/2018 because it's not an issue. 1. If the containing block has PaintOffsetTranslation, the floating object/column span will use both the container's paint offset and PaintOffsetTranslation, causing double paint offset;) 2. If there are any other paint property nodes between the containing block and the floating object/column span, the object will be incorrectly affected by the paint property nodes. This bug affects all slimming paint versions. It affects SPv1* by causing wrong visual rects. It affects SPv175+ by causing wrong display item lists to CC.
,
Mar 26 2018
I don't fully understand this bug. How can we ever have a composited layer without a paint offset translation? It seems like they wouldn't be able to invalidate correctly. Are we correctly avoiding invalidation of composited non-blocks when their position changes?
,
Apr 2 2018
For the following layout tree:
Paint-offset-root-of-containing-block
containing-block
paint-offset-root
target (float/column-span)
For the above case, target's paint offset is relative to paint-offset-root-of-containing-block instead of paint-offset-root, while currently its transform state is established by paint-offset-root. I think we should use containing-block's transform state as target's transform state.
For now for SPv1* we don't create PaintOffsetTranslation for a compositing layer that will be escaped by floats/column-spans to avoid the problem:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/paint/PaintPropertyTreeBuilder.cpp?rcl=f8ad0975f1c66b384f3bbb6ccd93b3831e0d98d3&l=468.
For SPv2, actually I'm not sure there is any case causing the issue. Tried some cases and none of them has the issue. However there would be issue if we supported transform for inlines. Is this still planned: https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/layout/LayoutInline.cpp?rcl=f8ad0975f1c66b384f3bbb6ccd93b3831e0d98d3&l=141?
,
Apr 2 2018
|
||
►
Sign in to add a comment |
||
Comment 1 by wangxianzhu@chromium.org
, Dec 6 2017Status: Assigned (was: Available)