Issue metadata
Sign in to add a comment
|
Extension popup window clicks are offset with second monitor in Windows
Reported by
erik.rot...@gmail.com,
Nov 20 2017
|
||||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/62.0.3202.94 Safari/537.36 Steps to reproduce the problem: 1. Open Chrome in second monitor 2. Click somewhere 3. The element beneath the mouse is not hit What is the expected behavior? It should target the element directly under the mouse What went wrong? A few users have reported that when clicking inside the extension popup of our extension the hitpoint is offset. This happens when the browser window is on a second monitor. WebStore page: https://chrome.google.com/webstore/detail/rss-feed-reader/pnjaodmkngahhkoihejjehlcdlnohgmp Did this work before? N/A Chrome version: 62.0.3202.89 Channel: stable OS Version: Windows 10 Flash Version: 62.0.3202.89 (Official Build) (64-bit) (cohort: 62_89_win) Revision4bc124ea2934343d106df5b937e78ce311311658-refs/branch-heads/3202@{#775}
,
Nov 21 2017
The issue needs to be tested on a dual monitor and the dual monitor set up is unavailable with ET-team. Hence, forwarding the issue to inhouse team by adding label TE-NeedsTriageFromHYD for further investigation. Thanks...!!
,
Nov 22 2017
Tested the issue on windows 10 with dual monitor using chrome M62 #62.0.3202.94 and M64 #64.0.3275.0 and followed the steps mentioned in comment #0. Attached screencast for reference. @ erik.rothoff-- Could you please check attached screencast for reference and let us know if we had missed any steps in reproducing the issue. Thanks!
,
Nov 22 2017
Hi, sorry, I totally missed a crucial step. Really sorry about that. One of the monitors should have different scaling. "And also I have different scale. On the first monitor: 125% On the second: 100%." From another user: "I have feeder on a Surface Pro 4 with a second monitor. If I have chrome open on the 2nd monitor, i.e. without custom scaling, feeder reads the mouse position as to the right and below its actual position as shown by the pointer, this makes the add-in unusable on that monitor. It doesn’t matter if the browser opens in that monitor, or opens on the Surface and I drag it onto the monitor, I get the same issue" I wonder if it is related to HDPI screens? There is another issue with the extension window on HDPI screens and with Chrome zoom that I'm struggling with too.
,
Nov 22 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
,
Nov 23 2017
Able to reproduce the issue on windows 10 using dual monitor scaling 150*100 using chrome M62 #62.0.3202.94 and M64 #64.0.3276.0 . This is a regression issue broken in M54. Using the per-revision bisect providing the bisect results, Good build: 54.0.2826.0 (Revision: 411209). Bad build: 54.0.2827.0 (Revision: 411497). Unable to provide the per-revision-bisect result , hence providing the manual chnagelog. Manual Chnagelog : https://chromium.googlesource.com/chromium/src/+log/54.0.2826.0..54.0.2827.0?pretty=fuller&n=10000 @Could someone help us in finding the actual suspect from the above manual chnagelog. Thanks!
,
Dec 29 2017
Same here - seems there is a problem with the pointer location calculations. It makes using two monitors interesting as the results are not always as expected!
,
Feb 1 2018
This seems to be a duplicate of: https://bugs.chromium.org/p/chromium/issues/detail?id=659642 Any news on this?
,
Mar 2 2018
|
|||||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||||
Comment 1 by manoranj...@chromium.org
, Nov 20 2017