Issue metadata
Sign in to add a comment
|
Tooltips in dev tools squished & mispositioned; overlays in app also not working
Reported by
ir...@coda.io,
Apr 2 2018
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/65.0.3325.181 Safari/537.36 Steps to reproduce the problem: 1. Open dev tools 2. Hover over any of the icons on the top that display a tooltip What is the expected behavior? What went wrong? Notice the tooltips are squished and mispositioned bottom and way to the right of the icon. Did this work before? Yes Chrome version: 65.0.3325.181 Channel: stable OS Version: OS X 10.11.5 Flash Version: This issue extends beyond just developer tools FYI. In our application, we have an absolutely positioned div that is repositioned via transform+translate CSS on every animation frame. That div is also being squished and positioned a few dozen pixels to the right of where it's suppose to be. Can provide more info it's it helpful. This issue was also hit by a customer. His specs: OS X 10.11.6 and Chrome 65.0.3325.162. We've tried it with another developer with the same exact OS & Chrome version as the customer, but it didn't repro.
,
Apr 3 2018
irvin@ Thanks for the issue. Tested this issue on Mac OS 10.13.1 and Windows 10 on the reported version 65.0.3325.181 and the latest Canary 67.0.3386.0 by following the steps mentioned above. On opening Devtools and hover on any icon, can observe the tool tip displaying correctly and no issues are observed. Attached is the screen cast for reference. As the issue is reported on Mac OS 10.11.5 and it is unavailable at TE end to test this issue, adding 'TE-NeedsTriageFromMTV' label and requesting someone from MTV team to look into this issue and help in further triaging. Thanks..
,
Apr 5 2018
Thanks for the report. Unfortunately I'm not able to reproduce either. > That div is also being squished and positioned a few dozen pixels to the right of where it's suppose to be. Can provide more info it's it helpful. Yes, please, extra information would be appreciated :) > We've tried it with another developer with the same exact OS & Chrome version as the customer, but it didn't repro. Hm, - were the two setups using different machines / monitor resolutions? - is the setup with the bug running any extensions? Could you try to reproduce it in incognito/guest profile?
,
Apr 9 2018
Thanks for the replies. It's an elusive bug for sure! After some searching, I found a public website that repros the "squished div" bug. Try visiting https://skiplagged.com/ and clicking on the fields with an autocomplete dropdown. Here's what it's suppose to look like (repro'd on coworker's computer, same Chrome v65.0.3325.181, different OS X 10.13.2): https://cl.ly/3P0f171i2D1o/Screen%20Recording%202018-04-08%20at%2007.07%20PM.gif And what I see: https://cl.ly/2T0M3K3O2X34/Screen%20Recording%202018-04-04%20at%2011.14%20AM.gif. Notice how when I hover and click over the seemingly empty space, I'm actually interacting with the "squished div" on the right. And here's me inspecting the dropdown element: https://cl.ly/431d1N2A2d0I/Screen%20Recording%202018-04-08%20at%2007.14%20PM.gif > were the two setups using different machines / monitor resolutions? Yes, though on my machine, the bug seems to repro independent of which monitor/resolution I use. > is the setup with the bug running any extensions? Could you try to reproduce it in incognito/guest profile? Yup it reproduces in incognito and guest profile. I've been hunting this bug down for weeks to fix the reported customer issue. Funny enough, by pure coincidence my machine suddenly started seeing that bug one day, likely due to a recent Chrome update.
,
Apr 16 2018
Requesting luoe@ to follow up on the bug.
,
Apr 16 2018
I'm unable to reproduce on Mac 10.13.3, Chrome 64.0.3282.186, 67.0.3394.0. Seeing from the GIF that it also occurs without DevTools open, it looks like it could be a general rendering issue. Maybe other teams have ideas?
,
Apr 16 2018
Please attach the output of visiting "chrome://gpu" for a working and non-working machine. This seems to be a problem with a composited layer getting a really odd transform when it should not and I strongly suspect different GPU configurations given the issues we've had with Mac drivers.
,
Apr 20 2018
Attached are the outputs of "chrome://gpu"
,
Apr 30 2018
The NextAction date has arrived: 2018-04-30
,
May 21 2018
Mac triage: assigning to schenney@ for followup.
,
May 21 2018
The first thing that jumps out is that the working and non-working differ in their Hardware Rasterization setting. irvin@, there is a chrome://flags setting for "GPU Rasterization". I suspect disabling or force enabling that will reproduce the issue. Could you try that and report your findings?
,
May 21 2018
,
May 21 2018
,
May 21 2018
Hey schenney – here are the results for setting GPU Rasterization: * Disabled – No noticeable changes; I still see the same tooltip & broken overlays bug. * Enabled – I see https://cl.ly/012C1l0q0u1K/Image%202018-05-21%20at%2012.02.00%20PM.png * Forced-enabled – Same as enabled I attached the output of chrome://gpu I also tried the same three flags on a coworker's machine. Switching among the three flags did not repro the issue. Let me know if there anything else you'd like me to try!
,
Jun 4 2018
The NextAction date has arrived: 2018-06-04
,
Jun 14 2018
As a quick update – I've recently updated to OS 10.13.5 and the issue is now fixed.
,
Jun 14 2018
Thanks very very much for giving us the update.
,
Jul 16
Mac triage: WontFix per #17 as obsolete. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by viswa.karala@chromium.org
, Apr 3 2018