Composited, paginated inlines have incorrect composited offset
Reported by
permanen...@gmail.com,
Nov 21 2016
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.98 Safari/537.36 Example URL: Steps to reproduce the problem: 1. Make a two-column layout using CSS 'columns' property. 2. Write a text and add a link (A tag) so that it appears as the first piece of text at the top of the second column. 3. Add a transition to the hover opacity on the link 4. Hover over the link. It jumps to the bottom of the first column (but outside the regular text flow). What is the expected behavior? The opacity of the link will transition and the element will remain in the same place. What went wrong? The link is re-positioned. Does it occur on multiple sites: N/A Is it a problem with a plugin? N/A Did this work before? Yes Chrome 52 Does this work in other browsers? Yes Chrome version: 54.0.2840.98 Channel: stable OS Version: OS X 10.11.6 Flash Version: Shockwave Flash 23.0 r0 Happens in Windows and macOS; also in newest versions of Opera which use the newest version of Chromium.
,
Nov 21 2016
,
Nov 24 2016
permanent.tourist@ In order to triage this issue could you please help us with the sample HTTP code, so that we can reproduce the scenario from our end. Thank You...
,
Nov 24 2016
How/where would you like it?
,
Nov 28 2016
You can just attached a sample html file to this bug report. The link to do so is right under the comment box. This is either a layout issue with the position changing on the hover, or a compositing issue with the opacity influencing painting. Not sure which without a test case.
,
Dec 1 2016
The easiest way is to provide the real-world example where the issue occurrs. Visit https://frappant.ch/support/?linkjump=1 in desktop resolution with the specified GET parameter using the indicated version of Chrome. Hover over the link “webmail.cyon.ch” in the “E-Mail” section of the page. The link moves around. Call the same page without the GET parameter and the opacity rule defined in https://frappant.ch/typo3conf/ext/frp_chromebug/Resources/Public/Css/frp_chromebug.css isn't applied. That is the only difference between the two versions of the page.
,
Dec 8 2016
Thank you for providing more feedback. Adding requester "kkaluri@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Dec 12 2016
The issue is that the opacity style change on the hover causes the link to get laid out as a separate span (or something) that for some reason causes it to change position. Not sure why but it's a multi-col layout issue, not painting.
,
Dec 13 2016
Thanks schenney! Over to Morten fur further triage.
,
Dec 14 2016
,
Dec 14 2016
The inline is composited during the transition. Chris, how do we handle compositing in multi-col?
,
Dec 16 2016
I'll take a look. Basically, multi-col is not allowed outside of compositing. i.o.w it's not legal to fragment a composited layer.
,
Mar 8 2017
Since we don't allow fragmentation of composited content, we can't position composited content on the second column. Instead maybe we can simply force a single fragment, but position it in the location the first fragment would have started. I'l prototype that.
,
Mar 8 2017
This example renders the text at the wrong position:
<!DOCTYPE html>
<style>
#target {
display: inline;
position: relative;
will-change: transform;
}
</style>
<div style="columns:2; column-fill:auto; width:15em; height:40px; line-height:20px; orphans:1; widows:1;">
<br><br>
<div id=target>text</div>
</div>
but changing #target to display: inline-block renders fine. That is the core bug I think.
,
Mar 8 2017
,
Mar 8 2017
,
Mar 10 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/a1277dcaaae26865cc6591bda0d6d696b5a0f073 commit a1277dcaaae26865cc6591bda0d6d696b5a0f073 Author: chrishtr <chrishtr@chromium.org> Date: Fri Mar 10 03:55:52 2017 Fix position of composited, paginated inlines. Previously, we were not including the offset from the PaintLayer of the composited layer when calling PaintLayer::visualOffsetFromAncestor to compute GraphicsLayer offset from the composited ancestor. It's important to include this offset when converting from logical to visual coordinates across a paginated layer boundary, because the offset influences the fragment offset of the composited layer. BUG= 667213 CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Review-Url: https://codereview.chromium.org/2738943004 Cr-Commit-Position: refs/heads/master@{#455982} [add] https://crrev.com/a1277dcaaae26865cc6591bda0d6d696b5a0f073/third_party/WebKit/LayoutTests/paint/pagination/composited-paginated-inline-expected.html [add] https://crrev.com/a1277dcaaae26865cc6591bda0d6d696b5a0f073/third_party/WebKit/LayoutTests/paint/pagination/composited-paginated-inline.html [modify] https://crrev.com/a1277dcaaae26865cc6591bda0d6d696b5a0f073/third_party/WebKit/Source/core/layout/compositing/CompositedLayerMapping.cpp [modify] https://crrev.com/a1277dcaaae26865cc6591bda0d6d696b5a0f073/third_party/WebKit/Source/core/paint/PaintLayer.cpp [modify] https://crrev.com/a1277dcaaae26865cc6591bda0d6d696b5a0f073/third_party/WebKit/Source/core/paint/PaintLayer.h
,
Mar 10 2017
|
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by ajha@chromium.org
, Nov 21 2016