Issue metadata
Sign in to add a comment
|
Iframe jumping when outline applied
Reported by
tom...@gmail.com,
Mar 26 2018
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.45 Safari/537.36 Example URL: https://zeroid.qc.to/temp/chrome_outline_jumping/ Steps to reproduce the problem: 1. Go to https://zeroid.qc.to/temp/chrome_outline_jumping/ 2. Move mouse over links What is the expected behavior? The iframe should stay in the same position What went wrong? The iframe jumping around the screen Does it occur on multiple sites: Yes Is it a problem with a plugin? N/A Did this work before? Yes 65.0.3325.181 Does this work in other browsers? Yes Chrome version: 66.0.3359.45 Channel: beta OS Version: 10.0 Flash Version:
,
Mar 26 2018
,
Mar 27 2018
I'm currently getting an error trying access the repro URL, so can't verify myself, but is the iframe in question here cross-origin? If so, can you see if disabling site isolation trials via chrome://flags/#site-isolation-trial-opt-out helps at all? We're experimenting with site isolation on beta/dev/canary, so they might affect this.
,
Mar 28 2018
Unable to access repro. Will check back in a week or once further clarification is provided.
,
Mar 28 2018
The display error happens using same origin html file, booth with and without iframe sandboxing. Opting out from chrome://flags/#site-isolation-trial-opt-out does not helps. The url should work (tested from different locations), but attached the reproduction files.
,
Apr 3 2018
The NextAction date has arrived: 2018-04-03
,
Apr 4 2018
,
Apr 17 2018
,
Apr 17 2018
tomper@ Thanks for the issue. Able to reproduce this issue on Windows 10, Mac OS 10.12.6 and Ubuntu 14.04 on the latest Canary 68.0.3398.0 and latest Stable 66.0.3359.117 as per the original comment. Bisect Information: =================== Good Build: 66.0.3344.0 (Revision - 535592) Bad Build : 66.0.3345.0 (Revision - 536026) On executing the per-revision bisect script, below is the Changelog URL: https://chromium.googlesource.com/chromium/src/+log/e04a14f4769d6b33b32686ccc3414e917a625ae7..a5676deb1e679035678bc1ed997518cd226378b9 From the above Changelog, suspecting the below change: Reviewed-on:https://chromium-review.googlesource.com/857902 skobes@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner. Adding ReleaseBlock-Stable for M-66 as this is a recent regression. Please feel to remove if this is not applicable. Thanks.
,
Apr 17 2018
Looks like an RLS layer positioning bug with a complex set of triggers. Scope and severity doesn't warrant RBS. As a workaround, you can add "will-change: transform" to the <body> element inside the iframe (frame.html).
,
Apr 17 2018
,
Apr 24 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/7153d60e8eb3c6559a3a06aaba072472f0cc325f commit 7153d60e8eb3c6559a3a06aaba072472f0cc325f Author: Steve Kobes <skobes@chromium.org> Date: Tue Apr 24 21:47:35 2018 Fix position of document GraphicsLayer in iframe with outline. In RLS mode, the position of an iframe LayoutView's main GraphicsLayer must account for any offset from the border or outline styling of the <iframe> element. Previously there were two different codepaths for applying this offset: (1) LayoutView's CLM in the child frame's compositing update (2) LayoutIFrame's CLM in the parent frame's compositing update If both frames are invalidated at the same time, path (1) breaks, because the parent document's lifecycle state disallows the child frame's compositing queries. Having two paths is also error-prone. This patch removes (1) in favor of using (2) exclusively. Bug: 825775 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Change-Id: I00cf19be083081315e7918efc1ebd2af00cae906 Reviewed-on: https://chromium-review.googlesource.com/1020146 Commit-Queue: Steve Kobes <skobes@chromium.org> Reviewed-by: David Bokan <bokan@chromium.org> Cr-Commit-Position: refs/heads/master@{#553296} [add] https://crrev.com/7153d60e8eb3c6559a3a06aaba072472f0cc325f/third_party/WebKit/LayoutTests/compositing/iframes/layer-position-with-outline-expected.html [add] https://crrev.com/7153d60e8eb3c6559a3a06aaba072472f0cc325f/third_party/WebKit/LayoutTests/compositing/iframes/layer-position-with-outline.html [modify] https://crrev.com/7153d60e8eb3c6559a3a06aaba072472f0cc325f/third_party/blink/renderer/core/paint/compositing/composited_layer_mapping.cc [modify] https://crrev.com/7153d60e8eb3c6559a3a06aaba072472f0cc325f/third_party/blink/renderer/core/paint/compositing/composited_layer_mapping.h
,
Apr 26 2018
Verified in canary (68.0.3409.0).
,
May 9 2018
Requesting merge to M67.
,
May 9 2018
,
May 9 2018
This bug requires manual review: M67 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
May 9 2018
Per comment #10 this is P2, not "RBS" and regressed in M66. I'm leaning towards to not taking this merge in for M67 as it is going to stable soon and we're only taking absolutely critical merges in. Pls let me know ASAP if there is any concern here. Thank you.
,
May 9 2018
That's fine, I was asked to merge on issue 841073 but in my opinion it is not high priority.
,
May 9 2018
Rejecting merge to M67 based on comment #19. Thank you. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by bokan@chromium.org
, Mar 26 2018Labels: -Type-Bug -Pri-2 OS-Linux Pri-1 Type-Bug-Regression
Status: Untriaged (was: Unconfirmed)