Issue metadata
Sign in to add a comment
|
GitHub reactions tooltips disappear when animating on main thread
Reported by
vsemozhe...@gmail.com,
Apr 10 2018
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3393.0 Safari/537.36 Example URL: Any GitHub issue or PR with reactions Steps to reproduce the problem: 1. Go to https://github.com/nodejs/node/pull/19910 2. Hover the mouse above any post reaction What is the expected behavior? Tooltip with reaction authors is shown. What went wrong? Tooltip with reaction authors is not shown. Compare 67.0.3386.1 dev versus 67.0.3393.0 canary screenshots. Does it occur on multiple sites: N/A Is it a problem with a plugin? No Did this work before? Yes At least 67.0.3386.1 dev is currently OK Does this work in other browsers? Yes Chrome version: 67.0.3393.0 Channel: n/a OS Version: 6.1 (Windows 7, Windows Server 2008 R2) Flash Version: 29.0.0.147
,
Apr 10 2018
,
Apr 10 2018
,
Apr 10 2018
This is weird. I see the bug on Windows 67.0.3393.0 canary, but not when bisecting. The bisect tool stops at r549371 while the Canary claims to be r549377, but nothing in the range 549371 to 549377 looks like it would cause this. I'll look at ToT to see what I can find. Maybe test could try bisecting again tomorrow.
,
Apr 10 2018
I just recently learned that the bisect script pulls a random finch config on every run. I wonder if that could be messing you up. Can you try bisect with the RLS and SPV175 flags? --root-layer-scrolls --enable-blink-features=SlimmingPaintV175
,
Apr 11 2018
A note: if you click any mouse button (left, middle, right) on the reaction number, the tooltip appears (for a moment or persistently).
,
Apr 11 2018
It seems fixed in 67.0.3394.0 canary.
,
Apr 11 2018
Observations: 1. Issue is not seen in 67.0.3390.0 canary build, upgraded chrome canary and observed build as 67.0.3393.4, Issue is seen here. Issue is seen in 67.0.3394.0 canary on Mac and Windows as well. 2. Issue is not seen in canary equivalent signed/unsigned dev. 3. Issue is seen in 67.0.3393.0 Linux but not seen in 67.0.3394.0. 4. As per comment#5 checked by enabling those flags -- observed tooltip on hovering. 5. Tried bisecting with per-revision bisect Good: 67.0.3390.0 and Bad: 67.0.3393.0 -- Observed RuntimeError: We don't have enough builds to bisect. revlist: []. 6. Hence performed with chromium bisect: python bisect_builds.py -a mac -g 548636 -b 549377 -- --enable-blink-features=SlimmingPaintV175 --root-layer-scrolls -- observed all good builds. As issue is reproducible from TE end on canary but not seeing on equivalent dev, hence marking as Untriaged and removing Needs-Bisect label. Please change if not the case.
,
Apr 11 2018
It seems this is flaky in 67.0.3394.0 canary on Windows.
,
Apr 11 2018
I still see the bug. No luck bisecting with SPv175 and root layer scrolls disabled/enabled. vsemozhetbyt@, could you navigate to chrome://version and add the "Variations" to this bug report? How do we map Variations onto experiments? My non-working variations for 67.0.3394.0 on Windows are: c134752e-ca7d8d80 411b6d4e-f23d1dea fe69e053-83ce3e87 5f419cc9-ca7d8d80 59aeb88e-3f4a17df 34a6bf44-ca7d8d80 a6674cf-ca7d8d80 f113d3c9-1d945ce0 9041608a-3f4a17df 1e528f0f-ca7d8d80 b130ecb8-2e32ee7e 6025934e-3f4a17df c27fec31-c982d8da 7c1bc906-b5809d46 3eb101d6-f23d1dea 47e5d3db-3d47f4f4 125b7f68-65bced95 41e765a5-f23d1dea 589b4e9f-3f4a17df f15c1c09-ca7d8d80 f9884634-659882c0 3042ad4b-cf4f6ead 591576c8-ca7d8d80 e56c5101-f23d1dea ceff87ec-f23d1dea 44827ee5-43146c13 4b61504a-a8ff754b 5485fc4d-3d47f4f4 937cad47-65bced95 9773d3bd-ca7d8d80 93731dca-e89d496c 8fa604e0-ca7d8d80 a428bf14-cabf6f65 9e5c75f1-e406a769 350fabdd-1cf80f06 f79cb77b-3f4a17df 4ea303a6-12cf3388 b19465ab-ca7d8d80 bcc34a89-87c9600e d92562a9-65bced95 7aa46da5-c946b150 2b33233e-d8253d6f 14c5a050-ca7d8d80 2c1d398c-3f4a17df 6973a1cf-f23d1dea 1d085b67-1410f10 ad6d27cc-15e2aa9a 2a32876a-f23d1dea f242806f-5810b593 4d17cf02-ca7d8d80 f3ea30a0-84708353 23496387-4ea78229 344833e9-473e8c2e 4bc337ce-69465896 57789a80-2d8bc89 9a2f4e5b-f46d6bfd 9b8b36ce-3f4a17df 494d8760-52325d43 3ac60855-3ec2a267 f296190c-31d50f90 4442aae2-4ad60575 ed1d377-e1cc0f14 12e17bc5-e1cc0f14 75f0f0a0-6bdfffe7 e2b18481-6bdfffe7 e7e71889-4ad60575 3a8271ac-48d1664a 3a4029d-f23d1dea bbb8f811-f23d1dea 98426e68-ca7d8d80 cc73f8a1-f23d1dea 81c6897f-870290a7 493ac2c5-ca7d8d80
,
Apr 11 2018
I too see flaky Canary. The working version has these additional 3 Variations. 34a6bf44-ca7d8d80 937cad47-65bced95 3a8271ac-48d1664a But none seem relevant unless the tooltip is coming from a server distinct from the other content.
,
Apr 11 2018
Variations c134752e-6d5b49a5 411b6d4e-f23d1dea fe69e053-94941f92 5f419cc9-ca7d8d80 34a6bf44-3d47f4f4 31101bd6-f23d1dea a6674cf-325621bb da89714-3de3103 64da5c1e-1e3265d 9041608a-f23d1dea 8502ae4f-6b5e5ddf 1e528f0f-ca7d8d80 b130ecb8-2e32ee7e 6025934e-3f4a17df c27fec31-c982d8da 7c1bc906-86bf56d9 3eb101d6-f23d1dea 47e5d3db-3d47f4f4 125b7f68-e872b86f 41e765a5-f23d1dea 459a590c-349050d8 589b4e9f-f23d1dea f15c1c09-6db57ab1 f9884634-659882c0 3042ad4b-f23d1dea 121ae2bc-ca7d8d80 591576c8-a8bffb1 e56c5101-3f4a17df 267255c3-f23d1dea ceff87ec-3f4a17df 44827ee5-3f4a17df 4b61504a-a8ff754b 5485fc4d-3d47f4f4 9773d3bd-ca7d8d80 93731dca-cdcbcaf4 8fa604e0-f23d1dea c992f345-4ad60575 9e5c75f1-db4fb466 f79cb77b-3f4a17df fb4ab4bb-3f4a17df 4ea303a6-2108e188 b19465ab-ca7d8d80 bcc34a89-ca7d8d80 7aa46da5-c946b150 2b33233e-881ca6c9 14c5a050-ca7d8d80 2c1d398c-9597b6c7 6973a1cf-3f4a17df 1d085b67-c49ac49f ad6d27cc-1627c3cf 2a32876a-ca7d8d80 4d17cf02-3f4a17df f3ea30a0-27a0c3c6 23496387-4ea78229 344833e9-1525b35b 3f273a97-25a103a9 4bc337ce-69465896 57789a80-f23d1dea 9a2f4e5b-515aa14b 9b8b36ce-3f4a17df 494d8760-52325d43 3ac60855-486e2a9c f296190c-97304ce3 4442aae2-d7f6b13c ed1d377-e1cc0f14 12e17bc5-e1cc0f14 75f0f0a0-4ad60575 e2b18481-bca011b3 e7e71889-4ad60575 3a8271ac-48d1664a a8e91bf2-f23d1dea 3a4029d-f23d1dea bbb8f811-f23d1dea 98426e68-ca7d8d80 cc73f8a1-f23d1dea 493ac2c5-72e357a3
,
Apr 11 2018
And broken again with the only variation that could be causing problems being something related to form autofill. All this suggests a race condition of some kind, or maybe some random variation not explicitly reported. The problem is that the initial reported working version could be wrong then.
,
Apr 11 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 11 2018
chrome://gpu is identical in working/not-working cases.
,
Apr 11 2018
,
Apr 16 2018
This issue is marked as a release blocker with no milestone associated. Please add an appropriate milestone. All release blocking issues should have milestones associated to it, so that the issue can tracked and the fixes can be pushed promptly. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 16 2018
This is an invalidationbug. When the button with the emoji is hovered, a ::before and ::after element is activated on the button, through .tooltipped:hover::before CSS. Using Devtools, the tooltip will appear if you force hover and then modify the animation on the ::before element. The animation moves opacity from 0 to 1. If you explicitly set the opacity to 1 then the tooltip always appears. In cases where the tooltip does not appear, the animation has run, and the opacity is 1, but the content is still not visible. What changes recently would cause this?
,
Apr 16 2018
,
Apr 16 2018
This looks highly suspicious. https://chromium.googlesource.com/chromium/src/+/c1e02b886cd8c543f242f3db2b75cd48ef0b6a82%5E%21/#F0
,
Apr 16 2018
M67 Beta promotion is coming VERY soon. Pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.
,
Apr 16 2018
,
Apr 16 2018
Looks like we've managed to identify the cause, or at least the change that caused the bug to manifest. Coming up with an action plan now.
,
Apr 16 2018
Just to update: To be able to 100% repro this issue, change this line https://cs.chromium.org/chromium/src/content/public/common/content_features.cc?l=412 To "base::FEATURE_ENABLED_BY_DEFAULT". The above config is used to conduct an experiment on Canary and Dev channel. People seeming this flaky because 50% is under experiment group which will have the text disappear, and another 50% will have normal behavior. The best way to handle this is for me to terminate that experiment, once I terminate that, everything will back to normal. There is no need for chromium side code changes.
,
Apr 16 2018
CCing chrishtr@: looks like moving opacity and 2D transform to main thread could break something. I am going to terminate the experiment now and take further investigation.
,
Apr 16 2018
I have terminated the experiment, it should take a few mins to config everything. And after that, we should not see this behavior again.
,
Apr 16 2018
Update: I tried this on my Linux workstation, for about 20 times and I am seeing the expected behavior now. vsemozhetbyt@, schenney@: could you try it now on your win machines and verify that you are seeing the expected behavior?
,
Apr 16 2018
vsemozhetbyt@, schenney@: you will need to restart chrome to see the change.
,
Apr 16 2018
I could not reproduce it with several attempts. In other words, we seem to be OK. Once another person verifies, we change the priority to 2 and assign it to someone to look at the underlying issue of running these animations on main thread.
,
Apr 16 2018
Sorry, I cannot understand what should I change to verify fixing.
,
Apr 16 2018
vsemozhetbyt@: no need to change anything. Please restart chrome canary, and check if you can repro this bug or not. Please have 5+ attempts by restarting chrome.
,
Apr 16 2018
All you need to do is be sure to restart Chrome. Experiments, the thing that caused this to manifest, are pulled from servers each time that Chrome starts. SO a restart will pull a new experiment configuration and should correct the behavior. Note that experiments like this one are designed to test performance changes with no effect of any kind on the users' experience (beyond changed performance characteristics).
,
Apr 16 2018
I can confirm that issue is gone in the Canary now.
,
Apr 16 2018
Thank you!
,
Apr 16 2018
Re-assigning to get the underlying bug fixed. And renaming now that we know the cause. Also removing release blocks. To reproduce, follow the instructions in comment #24. This looks to be an invalidation issue because the ComputedStyle shows opacity 1, yet the element is not displayed. And there is no repaint issued on the animating content according to devtools. xidachen@, what bug is this blocking?
,
Apr 18 2018
,
Apr 18 2018
This seems to be caused by SPv175 (I think); see:
smcgruer@stiglet2:~/chromium/src$ git diff
diff --git a/content/public/common/content_features.cc b/content/public/common/content_features.cc
index 2064459fc347..7e9cee0bb84e 100644
--- a/content/public/common/content_features.cc
+++ b/content/public/common/content_features.cc
@@ -416,7 +416,7 @@ const base::Feature kTouchpadAndWheelScrollLatching{
// An experiment to turn off compositing for 2D transform & opacity animations.
const base::Feature kTurnOff2DAndOpacityCompositorAnimations{
"TurnOff2DAndOpacityCompositorAnimations",
- base::FEATURE_DISABLED_BY_DEFAULT};
+ base::FEATURE_ENABLED_BY_DEFAULT};
// Enables unified touch adjustment which adjusts touch events target to a best
// nearby node.
smcgruer@stiglet2:~/chromium/src$ git diff
diff --git a/content/public/common/content_features.cc b/content/public/common/content_features.cc
index 2064459fc347..7e9cee0bb84e 100644
--- a/content/public/common/content_features.cc
+++ b/content/public/common/content_features.cc
@@ -416,7 +416,7 @@ const base::Feature kTouchpadAndWheelScrollLatching{
// An experiment to turn off compositing for 2D transform & opacity animations.
const base::Feature kTurnOff2DAndOpacityCompositorAnimations{
"TurnOff2DAndOpacityCompositorAnimations",
- base::FEATURE_DISABLED_BY_DEFAULT};
+ base::FEATURE_ENABLED_BY_DEFAULT};
// Enables unified touch adjustment which adjusts touch events target to a best
// nearby node.
# This reproduces the bug.
smcgruer@stiglet2:~/chromium/src$ ./out/Release/content_shell https://jsfiddle.net/tszynalski/kc2272ny/8/
# This doesn't.
smcgruer@stiglet2:~/chromium/src$ ./out/Release/content_shell --disable-blink-features=SlimmingPaintV175 https://jsfiddle.net/tszynalski/kc2272ny/8/
,
Apr 18 2018
(whoops; the git diff is shown twice because I am bad at copy/pasting. Sorry!)
,
Apr 18 2018
,
Apr 18 2018
Easier way to reproduce (without code change): out/Release/content_shell --enable-features=TurnOff2DAndOpacityCompositorAnimations https://jsfiddle.net/tszynalski/kc2272ny/8/
,
Apr 18 2018
,
Apr 30 2018
The NextAction date has arrived: 2018-04-30 |
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by susan.boorgula@chromium.org
, Apr 10 2018