:focus box-shadow rendering issues when animation on page
Reported by
etan.ber...@gmail.com,
Nov 21 2017
|
||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3265.0 Safari/537.36 Steps to reproduce the problem: 1. Add a box-shadow to a :focus on an input 2. Make sure there's also an animation on the same page that uses transform 3. click into the input box and the :input CSS rule won't appear 4. click again or type and the :input CSS should be applied properly What is the expected behavior? The CSS rule should be applied on initial interaction with an input. What went wrong? Here's a gif example: http://www.giphy.com/gifs/26u4kzsOHey9fgaoU Please note the input box-shadow IS NOT applied on first interaction with input! This is ONLY with Chrome. Worked fine on Firefox and Safari. When I removed the JS on the page, or the animation, the input CSS worked fine. Did this work before? N/A Does this work in other browsers? Yes Chrome version: 64.0.3265.0 Channel: n/a OS Version: OS X 10.12.6 Flash Version: This blog post shows a fix that works: https://www.sitepoint.com/fix-chrome-animation-flash-bug/ and a related Chromium bug from 2011 that I don't believe was fixed.
,
Nov 22 2017
Unfortunately, I can't share a PR with you but I copied most of our site in progress to this codepen: https://codepen.io/renagadex2/pen/jaxrGO You can see on initial load, if you focus on the input box, the box-shadow doesnt appear. however, if you interact with it, like add text, or move away from it and come back, it works fine. NOTE: this is only on chrome! Fire up firefox/safari and the box shadow appears on first touch.
,
Nov 22 2017
Thank you for providing more feedback. Adding requester "sc00335628@techmahindra.com" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Nov 24 2017
Able to reproduce this issue on reported version 62.0.3202.94 and on latest canary 64.0.3277.0 using Mac 10.12.6 , Windows 10 and Ubuntu 14.04 with attached HTML files in comment#0. Bisect Info: =============== Good Build: 52.0.2711.0 Bad Build: 52.0.2712.0 Unable to perform per revision bisect and chromium bisect as we are seeing RuntimeError: We don't have enough builds to bisect. revlist: [] error while bisecting. Even after changing range seeing same error while doing per-revision bisect and on doing chromium bisect builds are not getting invoked for above range. Hence providing changelog from Omahaproxy and assigning from it. CR: https://chromium.googlesource.com/chromium/src/+log/52.0.2711.0..52.0.2712.0?pretty=fuller&n=10000 Review URL: https://codereview.chromium.org/1895723002 Suspecting r387885 from changelog. @ tkent: Please confirm the issue and help in re-assigning if this is not related to your change. As tkent is OOO cc'ing keishi@chromium.org from cc list of 442484 Thanks!
,
Nov 27 2017
Not a regression if it regressed way back when. Not a P1 in this case either.
,
Dec 7 2017
Hi. Is there any update here?
,
Dec 7 2017
,
Dec 14 2017
,
Dec 19 2017
Also https://codereview.chromium.org/1809643008 is a possible candidate. Assigning to Rob to investigate.
,
Dec 21 2017
Reduction attached. My CL is the source of the bug, we're not doing a layout anymore when the box-shadow gets added as recomputing the overflow should be enough. The problem is that the element with the box shadow is getting clipped by an ancestor layer. The culprit is <div class="hologram-container"></div>. It's a stacking node and a composited layer, and when it has a zero height as in this case the root layer on the page gets a size that clips the subsequent elements in the page. See the attached screenshots: Zero-Height.png shows the size of the layer in orange when no height is specified on hologram-container, non-zero height shows what it is when a height of 1px is specified. There's a few things I don't understand here and I hope wangxianzhu can give me some pointers on: - hologram-container isn't a DOM ancestor of the siblings that its layer is clipping. Is that just how stacking nodes work? hologram-container is a stacking node ancestor of input-item here? - Seems like the fix here is to ensure that a non-zero height stacking node plus composited layer gets the same size as one that has a non-zero height. Or is there something I missing?
,
Dec 21 2017
I think this is a compositing issue that a squashing layer is not big enough to contain all visual overflows of squashed layers when a squashed layer's visual overflow enlarges. chrishtr@ can you take a look?
,
Dec 21 2017
It looks like a 0px height will-change before the input box div becomes a squashing-layer-container and a layer covering the input box gets added to it. While if the will-change div has 1px height (or above) nothing gets added to it and it doesn't become a squashing layer container.
,
Dec 22 2017
,
Dec 23 2017
The bug does not appear to be directly related to layer squashing. If I disable the feature, the bug still reproduces for the example in https://chromium-review.googlesource.com/c/chromium/src/+/842984
,
Dec 23 2017
--disable-layer-squashing doesn't seem to exist as a flag anymore. What do I use to disable it?
,
Dec 23 2017
I manually disabled it in the code. I also did some more debugging and found a deeper root cause, will update next week.
,
Dec 27 2017
I think the bug is that the text box is a layout root, then its overflow is computed during layout and not during RecalcOverflowAfterStyleChange. This leads to a situation where the text box does not apply its new overflow to its containing block, because layout started at the text box.
,
Dec 27 2017
I have a fix for this, stealing the bug.
,
Dec 27 2017
Issue 785641 has been merged into this issue.
,
Dec 27 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/d82391804bcc69b5979ad8a0ea60b1e808914363 commit d82391804bcc69b5979ad8a0ea60b1e808914363 Author: Chris Harrelson <chrishtr@chromium.org> Date: Wed Dec 27 23:39:14 2017 [PE] Recompute overflow after partial layout if overflow of the root changes. If LayoutObjet::ObjectIsRelayoutBoundary is true for a LayoutObject, dirty layout underneath it stops at that object. However, even though layout does not need to be recomputed outside of it, the LayoutObject's visual overflow can still change and affect overflow of surrounding content. Bug: 787565 Change-Id: I46d5c0a28fe247c4382154347d82d18491360452 Cq-Include-Trybots: master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Reviewed-on: https://chromium-review.googlesource.com/844994 Commit-Queue: Chris Harrelson <chrishtr@chromium.org> Reviewed-by: Christian Biesinger <cbiesinger@chromium.org> Cr-Commit-Position: refs/heads/master@{#526253} [add] https://crrev.com/d82391804bcc69b5979ad8a0ea60b1e808914363/third_party/WebKit/LayoutTests/fast/overflow/recompute-overflow-of-layout-root-container-expected.html [add] https://crrev.com/d82391804bcc69b5979ad8a0ea60b1e808914363/third_party/WebKit/LayoutTests/fast/overflow/recompute-overflow-of-layout-root-container.html [modify] https://crrev.com/d82391804bcc69b5979ad8a0ea60b1e808914363/third_party/WebKit/Source/core/frame/LocalFrameView.cpp [modify] https://crrev.com/d82391804bcc69b5979ad8a0ea60b1e808914363/third_party/WebKit/Source/core/frame/LocalFrameView.h [modify] https://crrev.com/d82391804bcc69b5979ad8a0ea60b1e808914363/third_party/WebKit/Source/core/layout/LayoutObject.cpp [modify] https://crrev.com/d82391804bcc69b5979ad8a0ea60b1e808914363/third_party/WebKit/Source/core/layout/LayoutObject.h
,
Dec 28 2017
,
Jan 3 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c572fd54978fe8f4b14f2dda91dbf2630d994db1 commit c572fd54978fe8f4b14f2dda91dbf2630d994db1 Author: Robert Hogan <robhogan@gmail.com> Date: Wed Jan 03 01:53:18 2018 Don't let empty layers artificially overlap with other layers This is a re-land of https://codereview.chromium.org/13431004 which was reverted nearly 5 yrs ago due to performance regressions at https://crbug.com/230147 . Changing an empty layer to 1x1 layer makes it artificially overlap with other layers so in the test case here a squashing layer gets created when none is needed. This creates an artificial need to resize the bogus squashing layer when its descendant objects overflow changes. It's worth trying again I think. Bug: 787565 Cq-Include-Trybots: master.tryserver.blink:linux_trusty_blink_rel;master.tryserver.chromium.linux:linux_layout_tests_slimming_paint_v2 Change-Id: Iff7ca289eef8480f99d30a84c9be77ee2c9e2289 Reviewed-on: https://chromium-review.googlesource.com/842984 Reviewed-by: Chris Harrelson <chrishtr@chromium.org> Commit-Queue: Robert Hogan <robhogan@gmail.com> Cr-Commit-Position: refs/heads/master@{#526577} [modify] https://crrev.com/c572fd54978fe8f4b14f2dda91dbf2630d994db1/third_party/WebKit/LayoutTests/paint/invalidation/compositing/column-span-under-composited-column-child-expected.txt [modify] https://crrev.com/c572fd54978fe8f4b14f2dda91dbf2630d994db1/third_party/WebKit/LayoutTests/paint/invalidation/invalidate-descendants-when-receiving-paint-layer-expected.html [modify] https://crrev.com/c572fd54978fe8f4b14f2dda91dbf2630d994db1/third_party/WebKit/LayoutTests/paint/invalidation/invalidate-descendants-when-receiving-paint-layer-expected.txt [delete] https://crrev.com/4d0cb45a390082634e82b36943145858f3e2a7d5/third_party/WebKit/LayoutTests/paint/invalidation/position/fixed-element-repaint-after-compositing-update-expected.txt [add] https://crrev.com/c572fd54978fe8f4b14f2dda91dbf2630d994db1/third_party/WebKit/LayoutTests/platform/mac/paint/invalidation/position/fixed-element-repaint-after-compositing-update-expected.txt [modify] https://crrev.com/c572fd54978fe8f4b14f2dda91dbf2630d994db1/third_party/WebKit/LayoutTests/platform/win/paint/invalidation/position/fixed-element-repaint-after-compositing-update-expected.txt [modify] https://crrev.com/c572fd54978fe8f4b14f2dda91dbf2630d994db1/third_party/WebKit/LayoutTests/virtual/spv175/paint/invalidation/compositing/column-span-under-composited-column-child-expected.txt [modify] https://crrev.com/c572fd54978fe8f4b14f2dda91dbf2630d994db1/third_party/WebKit/LayoutTests/virtual/spv175/paint/invalidation/invalidate-descendants-when-receiving-paint-layer-expected.txt [modify] https://crrev.com/c572fd54978fe8f4b14f2dda91dbf2630d994db1/third_party/WebKit/LayoutTests/virtual/spv175/paint/invalidation/position/fixed-element-repaint-after-compositing-update-expected.txt [modify] https://crrev.com/c572fd54978fe8f4b14f2dda91dbf2630d994db1/third_party/WebKit/Source/core/layout/VisualRectMappingTest.cpp [modify] https://crrev.com/c572fd54978fe8f4b14f2dda91dbf2630d994db1/third_party/WebKit/Source/core/paint/compositing/CompositingInputsUpdater.cpp
,
Feb 25 2018
Issue 815309 has been merged into this issue. |
||||||||||||
►
Sign in to add a comment |
||||||||||||
Comment 1 by sc00335...@techmahindra.com
, Nov 22 2017Labels: Triaged-ET Needs-Feedback Needs-Triage-M64