Issue metadata
Sign in to add a comment
|
Regression : Unnecessarily bidirectional arrow pointer is seen instead of arrow pointer.
Reported by
mni...@etouch.net,
May 19 2016
|
||||||||||||||||||||||
Issue descriptionVersion: 52.0.2741.0 19d105a2a1ec66924ff415f27ff170db7a67ba36-refs/heads/master@{#394609} (32/64-bit) OS: Windows (7,8,8.1,10) What steps will reproduce the problem? 1) Launch chrome and open NTP. 2) Now right click near avatar icon located on top RHS of browser in order to open context menu and move the mouse cursor along the top RHS portion of browser 3) Observe the mouse pointer Actual : Unnecessarily bidirectional arrow pointer is seen instead of arrow pointer while moving mouse pointer along top RHS of page. Expected : Arrow pointer should be seen This is a regression issue broken in 'M-48' and below is the manual regression and Narrow bisect info: Good build : 48.0.2529.0 Bad build : 48.0.2530.0 Narrow bisect info: https://chromium.googlesource.com/chromium/src/+log/230a6cc1034e196f24425502c50cd3d395995f2e..0e2df426e5110e0f94766d19bd33d3a732a0c1fb?pretty=fuller&n=10000 Suspecting : r352971 from Narrow bisect @pkasting : Could you please help to reassign if your change is not the cause for this change. Note : Issue is not seen on Linux and Mac OS.
,
Jul 9 2016
Moving this nonessential bug to the next milestone. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 25 2016
I can't seem to reproduce this on my Windows 10 Dev build. I'll have to try on my Windows 7 box (unless, reporter, you want to retest and see if you also can't reproduce anymore?).
,
Jul 26 2016
With response to comment #3 : Rechecked the above issue on Windows (7,8,8.1,10) with latest canary chrome version : 54.0.2807.1 and the issue is still reproducible.Please refer the attached screen cast for reference.
,
Jul 26 2016
OK, I need more information then. * Can you reproduce on a non-maximized window? * If no, can you reproduce on the left monitor of a two-monitor, side-by-side setup? If no, what about on the right monitor? * Precisely where are you right-clicking to open the menu? Your screencasts just snap the mouse over and click and I can't see where the pointer is. It would be nice to leave the mouse visible and unmoving for a second before opening the menu.
,
Jul 26 2016
With response to comment #5 : The above issue is reproducible only for the first instance.For non-maximized window issue is not reproducible.Please try to right click on the top edge of the browser window.Please refer the attached screen cast.
,
Jul 26 2016
I don't know what "the first instance" means, and the screen cast was unhelpful because you still whipped your mouse around like before, and then paused after clicking instead of before, but it doesn't matter. I can sometimes reproduce this. It's very inconsistent; the behavior feels random, and the cursor can change back and forth between the vertical resize cursor and the pointer repeatedly when moving the mouse to different places. I'll need to pull this up in a debugger and see if the hittesting function is returning something goofy.
,
Oct 3 2016
,
Oct 3 2016
,
Feb 14 2017
Not a priority -> out of my queue
,
Nov 2 2017
,
Sep 13
Archiving old bugs that haven't been actively assigned in over 180 days. If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!
,
Sep 13
Archiving old bugs that haven't been actively assigned in over 180 days. If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks!
,
Sep 13
Archiving old bugs that haven't been actively assigned in over 180 days. If you feel this issue should still be addressed, feel free to reopen it or to file a new issue. Thanks! |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by pkasting@chromium.org
, May 19 2016