Issue metadata
Sign in to add a comment
|
Regression? Chrome 57 changed 'pointer' cursor
Reported by
vphan...@gmail.com,
Mar 22 2017
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.110 Safari/537.36 Steps to reproduce the problem: 1. Hover mouse over any hyperlink What is the expected behavior? I expect to see the mouse pointer become the "pointer" cursor, a left-pointing white hand. What went wrong? Instead, I see a right-pointing black hand, somewhat skinnier with a long index. Did this work before? Yes 56.0.2924.87-1 (earlier today) Chrome version: 57.0.2987.110 Channel: stable OS Version: 4.2.0 Flash Version: Shockwave Flash 25.0 r0 Does Chrome contain its own pointers or did it change how it requests pointers from my Xorg setup? I only upgraded Chrome today so it's my prime suspect. (Firefox and Opera are NOT affected so far.)
,
Mar 22 2017
Unable to reproduce the issue on Ubuntu 14.04 using chrome stable 57.0.2987.110, navigated to web pages and mouse hovered on many links, hand pointer was displayed pointing on the link. No black hand was displayed. Could you please let us know on which flavor of Linux OS you are observing this. Thanks.!
,
Mar 22 2017
Thank you for your response. I am glad to see this may be a problem with my specific configuration and not a design choice from Chromium! :) $ uname -a Linux titan 4.2.0-0.bpo.1-amd64 #1 SMP Debian 4.2.6-3~bpo8+2 (2015-12-14) x86_64 GNU/Linux Other information which may be relevant: • OpenBox 3.5.3-8 • Xorg 7.7 • Xorg Intel driver 2.21.15-2 • Xorg mouse input driver 1.9.1-1 • All the files in /usr/share/icons/Adwaita/cursors/ date from 2014, and I checked each one and none is that right-black hand. (None of them is the left-white hand, either.) • I have no ~/.icons/ folder. • I don't have a ~/.config/gtk-3.0/settings.ini file. • $XCURSOR_THEME is not defined. • My ~/.Xdefaults only has a few lines specific to xterm; nothing general or for Chrome. • I created a brand new user, tried google-chrome and reproduced the issue, so this doesn't come from an extension.
,
Mar 22 2017
Thank you for providing more feedback. Adding requester "ranjitkan@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
,
Mar 22 2017
Same problem here. Plus, I've noticed that some links can't be clicked anymore in dropdown menus. Exemple here: https://jsfiddle.net/4usegpb5/ I can't click the "Click here" link in the dropdown menu with the left mouse button. Clicking with the middle mouse button works fine, though. UA: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/57.0.2987.110 Safari/537.36 OS: Debian Jessie The problem appeared after an apt-get upgrade (which upgraded Chrome and other packages).
,
Mar 22 2017
OP here, FYI in my Chrome 57 with the cursor issue, I can click the jsfiddle "Click here" link with my left mouse button without issue. Might be an unrelated issue.
,
Mar 22 2017
Looks like Chrome is now using XC_hand2 instead of XC_hand1 (https://tronche.com/gui/x/xlib/appendix/b/). I'll see if we can change this back
,
Mar 23 2017
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/f5067d43c3ea45f96b7716c1d4f42ef27d982e81 commit f5067d43c3ea45f96b7716c1d4f42ef27d982e81 Author: thomasanderson <thomasanderson@google.com> Date: Thu Mar 23 00:57:58 2017 X11: Use XC_hand2 instead of XC_hand1 This CL fixes a regression introduced in [1], where one instance of XC_hand2 was accidentally changed to XC_hand1. This made the cursor right-pointing instead of left-pointing [2]. [1] https://codereview.chromium.org/2504743002/ [2] https://tronche.com/gui/x/xlib/appendix/b/ BUG= 703982 R=derat@chromium.org Review-Url: https://codereview.chromium.org/2771733002 Cr-Commit-Position: refs/heads/master@{#458963} [modify] https://crrev.com/f5067d43c3ea45f96b7716c1d4f42ef27d982e81/ui/base/cursor/cursor_loader_x11.cc
,
Mar 23 2017
,
Mar 23 2017
Excellent news! Which future version will that fix fall into?
,
Mar 23 2017
It should appear in Chrome 59 or later, so it will be ~2 months before this hits stable. Alternatively, you could install google-chrome-beta or google-chrome-unstable if you want the fix sooner.
,
Mar 23 2017
Thank you. FYI if anyone's interested in an easy work-around until then, I detailed how I achieved it in a Gist: https://gist.github.com/vphantom/97d67328b55a1f1a11370a748da4dc03
,
Apr 27 2017
Issue 715980 has been merged into this issue.
,
May 25 2017
While the work around above didn't seem to work for me, changing my default pointer theme worked fine as a workaround for me while I wait for Chrome 59. Basically, I just symlinked the default theme to a different theme and the pointers in that theme were more to my liking. You can see more about that process here: https://askubuntu.com/questions/746139/gnome-3-how-do-i-get-the-same-mouse-cursors-in-chrome TL;DR: cd /usr/share/icons sudo ln -s Neutral default pkill chromium pkill chromium # I find that another couple of processes always respawn, thus this is needed twice <launch chromium> |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by nyerramilli@chromium.org
, Mar 22 2017