Issue metadata
Sign in to add a comment
|
Extension dropdown panel interaction incorrect on per-monitor DPI scaling systems
Reported by
drys...@gmail.com,
Jul 24 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/59.0.3071.115 Safari/537.36 Steps to reproduce the problem: 1. Use a Windows 10 system with different DPI scaling settings per monitor (e.g., primary monitor at 200% scaling, secondary monitor at 100% scaling) 2. Move the Chrome window to the non-primary monitor 3. Click an extension icon that shows a dropdown panel and try to interact with the mouse on any interactable elements on the dropdown. What is the expected behavior? Dropdown should be interactable as normal. What went wrong? The interactable areas of the elements are in the wrong spot. Probing around with the mouse seems to indicate the element's mouse interactions are all scaled to the secondary monitor's DPI incorrectly. In my case (primary monitor @ 200%, secondary @ 100%), all the interactive areas of the elements are 50% normal size. See the attached image for details. This problem appears to affect all mouse interaction; including clicks, drags, and which mouse cursor is shown when the mouse is at various locations over the dropdown. The attached image shows the dropdown from the Google Voice extension, but this problem *is not* specific to that extension; all extensions that show dropdowns with interactable elements have the same problem. Did this work before? Yes Unknown, but quite some time ago. I think it broke with the changeover to the material UI. Chrome version: 59.0.3071.115 Channel: stable OS Version: 10.0 Flash Version: Shockwave Flash 26.0 r0
,
Jul 26 2017
Tested the issue on windows 10 using chrome latest stable M60 #60.0.3112.78 and followed the steps mentioned in comment #0 . Had set the DPI of primary monitor to 200% and secondary monitor to 100 % and checked with the extensions interactable elements with mouse hover and didn't observe any weird behavior. @drysart-- Could you please update your chrome version to latest stable and set the chrome://flags to default and check if you can resporuce the issue and .. Please help us with the screencast for better understanding. Thanks!
,
Jul 26 2017
Updated to latest stable (Version 60.0.3112.78 (Official Build) (64-bit)) and reset flags to default; can confirm the issue is still present I did discover a new detail; however. I installed the Screencastify extension for Chrome to capture a cast of the issue, and as soon as I began recording through the extension, the problem went away; and was gone until I restarted Chrome, so there does appear to be at least one condition that fixes the problem. As a result, I switched over to use a non-Chrome screen recording software (OBS Studio) to capture the problem. I've attached the video. In the video, the mouse cursor is shown at an incorrect size (due to an unrelated issue with OBS and per-monitor DPI); but it is shown in the correct place, and with the correct cursor image. The video shows off as many different sorts of mouse interaction I could think of to show: cursor changing to show clickable/default/I-beam, clicking on a link, and moving a caret around in a textbox; all in the wrong scaled location. Also attached a screenshot of the Windows display settings app, showing the settings for both the primary and secondary display.
,
Jul 26 2017
Thank you for providing more feedback. Adding requester "hdodda@chromium.org" to the cc list and removing "Needs-Feedback" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 26 2017
Also, on my other display, set to 125% scaling; the same problem presents, just with the interactable region of the elements being slightly larger than they are on the 100% display. Attached is a video from that screen as well showing the difference.
,
Jul 27 2017
Tested the issue on windows 10 using chrome latest stable and M60 #60.0.3112.78 and M62 #62.0.3167.0 and observed as attached in screencast. @drysart-- Could you please check attached screencast and confirm us if this is the issue you are talking about and if we have missed anything in reproducing the issue. @Could someone from dev please help us in triaging the issue. Thanks!
,
Jul 27 2017
Yes, that appears to be exactly the issue.
,
Jul 28 2017
Able to reproduce the issue on Windows 10 dual monitor set up with 1st monitor having 200% resolution and 2nd monitor having 100% resolution using chrome reported version #59.0.3071.115 and latest canary #62.0.3168.0. Bisect Information: ===================== Good build: 54.0.2826.0 Revision(411209) Bad Build : 54.0.2827.0 Revision(411497) Change Log URL: https://chromium.googlesource.com/chromium/src/+log/5c2b9e90ae933ea112d9ca2f07c99ebf1f90d3b9..1127cbf181298f0eadfe8d7582a6b0a97c6922a8 From the above change log suspecting below change Review url: https://codereview.chromium.org/2122023002 wjmaclean@ - Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Note: Couldn't confirm on OS-Mac or OS-Linux due to non-availability of dual monitor setup. Thanks...!!
,
Jul 28 2017
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by nyerramilli@chromium.org
, Jul 26 2017