Issue metadata
Sign in to add a comment
|
Javascript style updates not always displayed immediately
Reported by
ste...@ontestpad.com,
Apr 13 2018
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Steps to reproduce the problem: 1. (maybe) Connect external monitor to 5K iMac 3. Launch Chrome (on main display of iMac) 4. Load this codepen: https://codepen.io/sbutlin/pen/RMmEPd 5. Click on Box1 several times, with (maybe) varying time interval between clicks What is the expected behavior? The box should always change colour immediately. What went wrong? The bgcolor change does not always happen immediately; sometimes it "sticks" indefinitely until the mouse moves far enough to e.g. change cursor because it hovers over some text or leaves the viewport, sometimes it only sticks for a few seconds without an obvious event to unstick it. Sometimes the failure rate is only 1 click in 20 show the problem. Other times every other attempt shows the problem. The delayed repaint is observed with other style changes too, e.g. absolute position changes, display:block/none changes. The problem can be observed even if historical repaint fixes are tried, including: - changing overflow - applying translate3d(0,0,0) - accessing an element's height to trigger a reflow after making the style change The problem has only be observed on an iMac 27" 5K with an external monitor connected (a Dell U2412M attached via thunderbolt). Could not reproduce on MacBook 12". Could not reproduce in Safari or Firefox. Could not reproduce with the external monitor disconnected (and after relaunching Chrome). Recording using the Performance Profiler does not capture the problem... the delayed repaint happens in live use (during recording), but inspecting the timeline shows screenshots as if the repaint had happened on time. I.e. whatever buffer the Dev Tool is reading for the screenshots has been correctly repainted, but this buffer has not made it to the display. Could not reproduce with CSS :hover trigger - these displayed on-time everytime. Disabling the 2d accelerated canvas did not help. No extensions installed. Did this work before? N/A Chrome version: 65.0.3325.181 Channel: stable OS Version: OS X 10.12.6 Flash Version: System: iMac (Retina 5K, 27-inch, 2017) 4.2 GHz Intel Core i7 40 GB 2400 MHz DDR4 Radeon Pro 580 8192 MB macOS Sierra 10.12.6 (16G29)
,
Apr 13 2018
Can TE reproduce this issue?
,
Apr 15 2018
,
Apr 16 2018
Could not test and confirm the issue from our end, as we do not have the setup(5k imac with dual monitor connection) hence removing label "Needs-TestConfirmation". Adding label TE-NeedsTriageFromMTV and requesting some one from MTV to have a look into it and help in further triaging it. Thanks!
,
Apr 16 2018
Cannot proceed further due to the lack of setup. stefan@ontestpad.com, would it be possible for you to help with bisect if its still reproducible? https://www.chromium.org/developers/bisect-builds-py
,
Apr 17 2018
Adding TE-Hardware-Dependency label to remove this issue from TE triaging bucket as TE team do not have above mentioned setup. Thanks!
,
Apr 17 2018
UPDATE: - external monitor is not relevant - but running OSX's "Digital Color Meter" is relevant - I can reliably reproduce only when the DCM is running, whether or not the external monitor is connected - MacBook 12" still does not show the problem, with or without DCM running - so still only happening with iMac 5K - and reconfirmed still only happening with Chrome The DCM's window, showing the pixel close-up, shows the same as the main display: i.e. when there is a delayed frame update, the DCM window also shows a delayed update. Tried a bisect with: python bisect-builds.py -g 38000 -b 530369 -a mac64 --use-local-cache --verify-range Several versions crashed on start up (not sure if that's normal), so they got flagged as unknown, but did find good and bad versions. Eventual output from bisect: You are probably looking for a change made after 254069 (known good), but no later than 254276 (first known bad). NOTE: There is a Blink roll in the range, you might also want to do a Blink bisect. CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/None..e8cf7555b1e2d6b8b32bc00ad69b44fe85b44a75 (I can share the full stdout of my bisect run if that's helpful)
,
Apr 20 2018
The NextAction date has arrived: 2018-04-20
,
Aug 17
ccameron: Assigning to you for mac graphics bug triage
,
Sep 14
I don't think this is mac-specific, I can't reproduce it locally. Maybe ->Paint triage?
,
Sep 14
,
Sep 17
stefan@, does this still reproduce in subsequent Chrome versions?
,
Sep 17
,
Sep 18
I can no longer reproduce. I've upgraded OSX to High Sierra 10.13.6 since reporting this issue. One possible clue - the Digital Color Meter now behaves differently than it did in OSX Sierra - in my test codepen, clicking to toggle the colour of the box works every time in Chrome, but no longer updates in DCM until the mouse moves. DCM used to track the colour with every click. DCM's new behaviour (no update until mouse move) is the same in Safari. FWIW, my install of Chrome is now Version 69.0.3497.81 (Official Build) (64-bit) - but OS has also changed, so can't say if this Chrome on Sierra on iMac5k would still be problematic.
,
Oct 1
The NextAction date has arrived: 2018-10-01
,
Oct 8
Given the digital color meter relationship, the specificity of setup required, and the OS update fixing things, I'm happy to say WontFix. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by schenney@chromium.org
, Apr 13 2018