Chromium

Unable to reproduce the issue on Linux 14.04 chrome version 41.0.2272.43- hand icon displays on placing the mouse over any link.

maybe issue related to chrome on virtual machine.

Yes, the issue is related to any Chrome beta and unstable in Virtualbox, as noted in the report. Real HW installs works fine.

It seems it's quite serious issue, as lot of Linux Chrome users is affected now.

I am also seeing this issue, and it appears to be related to the use of mouse integration on virtualbox - if mouse integration is disabled, mouse over actions work as expected.

Host OS: Windows 7 Pro SP1 (64 bit)
Guest OS: Xubuntu 14.04 LTS Desktop (64 bit)
Virtualbox (and guest additions) version: 4.3.20 / 4.3.22 / 4.3.24 (same issue on all)
Chrome version: 41.0.2272.76 (google-chrome-stable)

It looks like it's not VirtualBox, but Google-Chrome bug, as Chrome v.40 and all earlier versions are working fine.

Hate to post a "same here" report, but perhaps more details for those trying to re-create (originally posted at https://productforums.google.com/forum/#!category-topic/chrome/report-a-problem-and-get-troubleshooting-help/linux/Beta/3Kvz9eGm87M)


Problem
Since the update to Chrome v41 (or so it seems), my mouse has behaved erratically within Chrome. For example:
Hovering over a link does not display the link in the bottom corner as it used to, nor does the mouse icon change to a hand;
If the mouse pointer is over an image link, the mouse does not change to a hand, however if I force the display to update (such as by using the scroll-wheel) the pointer icon changes to the appropriate hand. If I subsequently move the mouse off the link the pointer remains the hand until I force a redraw again, such as by scrolling some more or moving the mouse off the Chrome window;
Click-and-drag does not highlight text, though double-clicking does, and a subsequent shift-click extends the highlight as expected;
If there is a scroll-bar on the right side, I am unable to click-and-drag the slider, but I am able to click below/above the slider and the display moves by a page length as expected;
If Chrome is not maximized, if I move my cursor at a normal speed INTO the Chrome window, the mouse point often remains that of the "drag-edge" icon (arrow with bar under Ubuntu, what is double-sided arrow in Windows). If I move fast enough it doesn't change. If I click somewhere inside the Chrome window, it reverts to "normal";
Moving the mouse over the toolbar buttons does not "highlight" the button, which is the usual hint as to which button is under the mouse. What is odd is that using the scroll-wheel while over a button triggers the appropriate highlighting, even though the window is not scrolled (not that it is supposed to scroll when the pointer is over the buttons);
There may be more symptoms, but I think this is enough to give you the idea!
I am running the same version of Chrome under Windows 7, and everything is behaving correctly. I have tried to re-install the guest additions and rebooted, but to no effect. Ubuntu is up-to-date. Note that the mouse behaviour in other apps seems unaffected.

Environment:
Running Chrome on Ubuntu in VirtualBox on Windows 7.

Chrome:
$ dpkg -l google-chrome* | grep ii
ii  google-chrome-stable 41.0.2272.76-1 amd64        The web browser from Google

Google Chrome   41.0.2272.76 (Official Build)
Revision        45d2489fbf9d0f9020010fe18ce8f6dcf0e2da9a-refs/branch-heads/2272@{#391}
OS      Linux
Blink   537.36 (@191030)
JavaScript      V8 4.1.0.21
Flash   16.0.0.305
User Agent      Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.76 Safari/537.36
Command Line    /usr/bin/google-chrome-stable --flag-switches-begin --flag-switches-end

Linux:
$ lsb_release -a
No LSB modules are available.
Distributor ID: Ubuntu
Description:    Ubuntu 14.10
Release:        14.10
Codename:       utopic

$ uname -a
Linux xxxxx-VB 3.16.0-31-generic #41-Ubuntu SMP Tue Feb 10 15:24:04 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux

VirtualBox:
VirtualBox-4.3.24-98716-Win

VirtualBox Guest Additions:
Oracle_VM_VirtualBox_Extension_Pack-4.3.24-98716

$ modinfo vboxguest
filename:       /lib/modules/3.16.0-31-generic/updates/dkms/vboxguest.ko
version:        4.3.24
license:        GPL
description:    Oracle VM VirtualBox Guest Additions for Linux Module
author:         Oracle Corporation
srcversion:     8E9DD4171D282029FBB2516
alias:          pci:v000080EEd0000CAFEsv00000000sd00000000bc*sc*i*

I have the exact same problem on Virtualbox guests Xubuntu & LinuxMint with hosts Windows 7 and 8.1. It happened with the Chrome 41 update. This is on Google chrome from Google not the Chromium derivative. In fact I removed Google chrome (GC) and installed chromium and it works fine. (alternative till GC gets fixed). The bug is probably in GC as mentioned earlier all the other software (firefox/chromium) works fine. This problems can be reproduced (for me at least) on all the combinations above and 32/64 bit variations as well. I've tried on guest additions that come with LinuxMint and later installed by manually, still I could see the problem. So far I haven't been able to rectify this issue. Hope it gets fixed soon.

Same Issue (mouse cursor not changing, text selection not working).  In a pinch, double clicking on words to select text does work, however this is far from ideal.

Host OS: Windows 7
Guest OSes tried: Ubuntu 14.04.2 x64, Linux Mint 17.1 x64
Chrome version: Version 41.0.2272.76 (64-bit)
VirtualBox Version 4.3.24

Disabling Mouse Integration fixes this for me, albeit in a nasty fashion. Downgrading to Chrome 40 fixes the issue.

How can I downgrade easily to v40?? Latest Chromium in ubuntu ppa is 37... WTF?

I cannot work with this bug. Every new Chrome version fucks everything up, I'm really sick of reporting bugs.

I'm having the same problem. I'm using VirtualBox on Windows 7, and this happens on Debian and Fedora 21. On CentOS 7 it works fine, though.

I've tried using the GTK+ theme, classic theme, enabling and disabling hardware acceleration, but nothing seems to solve the problem.

I hope this will be fixed very soon.

v41.02272.76 of Chrome is not playing nice with virtualbox mouse integration. Disabling it though 'Machine -> Disable Mouse Integration' solves the issue temporary.

Hopefully this will be resolved soon.

Can verify the bug using Windows 7, VirtualBox 4.3.22 r98236, Chrome 41.0.2272.76

Many hovering, drag/drop, text selections issues.

Same issue with Chrome 41.0.2272.76 (64 bits) on a VirtualBox Guest Debian Jessie over a Host VirtualBox 4.3.10_Ubuntu r93012.

Mouseover does not work.

Fixed the issue downgrading to chrome 40.

Same issue for me - mouseover not working anymore.

- Lubuntu 14.04.2 LTS as Guest on VirtualBox 4.3.22 (Host: Windows 7 64bit)
- Chromium 41.0.227276

No problems with Chromium 40.x

Same problem as well

- Xubuntu 14.04, Virtualbox 4.3.12
- Google Chrome 41.0.2272.76 (64-bit)

Using the mouse integration disable as a temporary solution.

I am also seeing this issue.

Host: Ubuntu 14.04
Guest: Linux Mint 17.1 "Rebecca"
Virtualbox: 4.3.24 r98716
Chrome (on guest): 41.0.2272.89 (64-bit)

Disabling mouse integration is a (helpfully extremely temporary) workaround.

I did not have this problem on Chrome 40.

This issue is pretty serious as it impacts basic usability. It should be fixed ASAP. I'm very surprised this kind of bug survived release testing, Google should improve their testing process to catch these basic kinds of bugs.

I've got the same problem too.  It started when I upgraded from:
google-chrome-stable-40.0.2214.111-1.x86_64 to google-chrome-stable-41.0.2272.76-1.x86_64

Host OS: Windows 7
Guest OS: Fedora 21 (kernel: 3.18.8-201.fc21.x86_64)
VirtualBox: 4.3.20

Does anyone know how I can get my hands on the google-chrome-stable-40.0.2214.111-1.x86_64.rpm so that I can downgrade to this version which was working for me? I've tried browsing to the yum repo but no joy: http://dl.google.com/linux/chrome/rpm/stable/x86_64

I can't seen to find anywhere where google provides an archive of previous versions.

Same problem. Xubuntu 14.04, VirtualBox 4.3.24 with guest addons, Google Chrome 41.

Same issues.

Virtualbox 4.3.12
Host: Windows Server 2008 R2 x64
Guests: Xubuntu 14.04 x64 and/or x86
Chrome: 41.0.2272.76

I have same issue:

Host: Ubuntu 14.10
Virtualbox: 4.3.22
Guest: Linux Mint 17.1 Xfce
Chrome: 41.0.2272.89 (64-bit)

Disabling mouse integration isn't workable for us because we work in seamless mode.

For those of you on Debian based systems you may be able to downgrade as we did (at your own risk):

Navigate to /var/cache/apt/archives as root
Open the latest version Chrome .deb file using GDebi and uninstall it
Open the previous Chrome .deb file using GDebi and install it, ignoring all warnings

Also affected,
Qemu KVM,  
Guest: CentOS 7 17.1 Xfce
Chrome: 41.0.2272.89 (64-bit)
remote client:Spice/QXL

seems to occur in virtualbox setups as well.
Can't resize windows, can't drag, right click functionality doesn't work as expected.
Disabling mouse integration is not an option on Spice clients.

Same issue here.

Linux Mint XFCE 17.1  64 bit
VirtualBox 4.3.24 for Windows hosts
Chrome 41.0.2272.76

Mouse no worky.

I'm having the same issue an in addition I cannot drag the scroll bar up or down.  My setup is as follows.

Chrome Version 41.0.2272.89 installed in Virtualbox
Guest Version Ubuntu 14.04.2 with Guest Additions 4.3.24
Host Windows 8.1 x64
VirtualBox Version 4.3.24

Here is a link to get Google Chrome 40 for those who want to downgrade as a temporary fix.

http://mirror.pcbeta.com/google/chrome/deb/pool/main/g/google-chrome-stable/

They are all *.deb packages if you need *.rpm you may have to convert this by your self.
Hope this helps and in the meantime the bug gets fixed.

previous versions of Google Chrome for Linux Debian derivatives.

link downgrade Google chrome (rpm packages)

http://mirror.pcbeta.com/google/rpm/i386/google-chrome32/

32-bit

(1) I cannot select text when I click and drag the mouse.  The cursor remains an arrow throughout the dragging and nothing is selected when I release the mouse button. Also, control-c doesn't put anything in the clipboard.  If I double-click or triple-click, I can select a word or paragraph, respectively, and the right-click context menu lets me copy to the clipboard.  At that point the cursor changes to an I-bar, but still won't select text.

(2) The vertical page slider (on the right of the page) does change color when I click it, but won't slide when I drag it.

(3) I haven't tested it rigorously, but I don't see hover behavior occurring on web pages that used to react to hover events.  Perhaps the browser thinks I'm on a tablet with a touch screen.

The problems occur when I use Chrome on Ubuntu 14 within Virtual Box 4.3.24. If I use Firefox within the same environment, everything is fine.  

Things I've done to try to fix the problems, but nothing helped:
1. Deleted config file
2. Cleared Cache and all temporary data
3. Reset browser
4. Re-installed browser
5. Changed zoom level

Within other environments (not Virtual Box), I sync Chrome across multiple machines and Chrome works fine on two other PCs and an iPad.



Chrome on Ubuntu is an important part of my daily work, so please let me know if I can provide any further info.

Version info:
---------------
Google Inc.
Copyright 2015 Google Inc. All rights reserved.
Google Chrome   41.0.2272.76 (Official Build) unknown
Revision        45d2489fbf9d0f9020010fe18ce8f6dcf0e2da9a-refs/branch-heads/2272@{#391}
OS      Linux
Blink   537.36 (@191030)
JavaScript      V8 4.1.0.21
Flash   16.0.0.305
User Agent      Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.76 Safari/537.36
Command Line    /opt/google/chrome/chrome --flag-switches-begin --manual-enhanced-bookmarks --flag-switches-end
Executable Path /opt/google/chrome/chrome
Profile Path    /home/tb/.config/google-chrome/Default
Variations      e9f4800b-39c30599
4b406b23-3f4a17df
3ac60855-486e2a9c
f296190c-6754d7b7
4442aae2-6bdfffe7
ed1d377-e1cc0f14
75f0f0a0-d7f6b13c
e2b18481-5c63917a
e7e71889-e1cc0f14

Downgraded as per https://crbug.com/chromium/456222#c32.
Weirdly enough, I had to do it a few times uninstall/install, I run Linux Mint 17 in VirtualBox and for some reason it was still launching the v 41 Chrome executable. A restart of the VM seems to have fix it. The Chrome process stays in memory even when you close the window?
Anyway, it works now as before, running Version 40.0.2214.91 (64-bit)

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

You can duplicate this problem if you download and install virtualbox from: https://www.virtualbox.org/wiki/Downloads
and then install the ubuntu 14.4 inside that from: http://www.ubuntu.com/download/desktop
And then install chrome from here:  https://www.google.com/chrome/browser/desktop/index.html

It may only work if the host system that you have virtualbox installed on is Windows.
I have made a brief video where I show the problem available here: http://youtu.be/rMpKGn8PLOk
and while you can't see where I click and drag in the Chrome window (that's kind of the the problem to begin with) you can clearly see that the cursor does not change.

chromium@googlecode.com writes:

I have the same problems with an OSX host.

I am having the same issue (No cursor change / Can't scroll with mouse cursor) with version 41+ but I am using VMWare Player and Fusion

Per posts #32 and #41, does anyone know where to get an older version of Chrome from an official source?  pcbeta.com looks a bit suspicious.

Problem still exists after upgrade from 41.0.2272.76 to 41.0.2272.89.

Note: this bug is way more severe than the title suggests. This bug makes Chrome just about unusable since text is not selectable, canvas areas not draggable, etc.

[Comment Deleted]

[Comment Deleted]

Yep, description not very good on this one. Most of the merged ins had more complete description. Example:
https://code.google.com/p/chromium/issues/detail?id=458291

Want to pipe in with "same issue here".
Problem affects only chrome and makes it entirely unusable.
I've tried playing around with enabling and disabling 3D and 2D acceleration in the VM settings to no avail.
Enabling and disabling hardware acceleration in Chrome flags had no effect either.

Host: Windows 8.1 Pro x64
VirtualBox: 4.3.24
VM: Ubuntu 14.04.2 LTS, Trusty Tahr
Chrome Version: 41.0.2272.89 (64-bit)

The same problem.

Same issue here.

Host: OS X 10.10.2
VirtualBox: 4.3.26
VM: SMP Debian 3.11.8-1 (2013-11-13) x86_64 GNU/Linux
Chrome: 41.0.2272.89 (64-bit)

Same issue here. Chrome 41 on Virtualbox 4.3.26

This issue title no longer covers the actual issue.  Please update it so the Chrome developers know the real issue breaks core functionality and don't ignore it as a minor visual glitch.  Or split out this new issue into it's own thread.

Title of "Mouse-over actions not affect the pointer" should be changed to something like: "Unable to 'drag to select text' in Chrome on Linux"

Host OS: Windows 8.1 Pro
VirtualBox:  4.3.26 r98988
Virtual Machine OS: XUbuntu 14.04 last updated 3/17/2015
Chrome: 41.0.2272.89 (64-bit)

Uninstalled, purged, and re-installed.  Deleted .config/google-chrome/ directory

Still occurring on my setup as well.

Host: Windows 8.1 (64-bit) Pro
VirtualBox: 4.3.26 r98988 (64-bit)
Guest: Ubuntu 14.10 (64-bit)
Guest Additions: 4.3.26
Chrome: 41.0.2272.89 (64-bit)

Able to repro this issue on Linux Ubuntu 14.04 41.0.2272.89.

Note: Virtualbox is installed on Windows, connected to Linux.

Host: Windows 7
Virtual Box: 4.3.26 r98988
Guest: Ubuntu 14.04
Chrome: 41.0.2272.89

Ligi, Could you please suggest, can we provide bisect for this issue.

Attaching screen-cast for supporting https://crbug.com/chromium/456222#c68#

[Empty comment from Monorail migration]

I have similar issue: mouse cursor does not react to link elements in Chrome but also i can't drag side scrollbar... and also not able to select any text with mouse.

Without the Vbox Guest Additions it works as it should.

Host: Windows 7 (SP1)
Virtual Box: 4.3.26 r98988
Guest: Fedora 20 (xfce)
Chrome: 41.0.2272.89 (64-bit)

Same issue here running VirtualBox Version 4.3.26 r98988 on Windows 7. Guest OS is Mint 17 running Chromium 41.0.2272.76



This is my old bug:

https://code.google.com/p/chromium/issues/detail?id=465727

Given the large amount of attention on this bug, I'm raising the priority and marking it as a release blocker for Chrome 42. (Chrome 41 is already released, so we can't block that - but if the fix is small it's not out of the question to port the fix there too - let's decide that later.)

Is anyone willing to run a bisect script to help figure out where this regressed?

It's pretty easy to use - you just run a single Python script and it downloads prebuild binaries - you answer whether each one is good or bad and it narrows down where the regression occurred.

http://www.chromium.org/developers/bisect-builds-py

If someone can run this script and paste the final output in this bug that will help a lot.

It's been pointed out that the link to bisect-builds.py is a bit of a pain.

I've attached it below, just download it and run it.

If no-one else takes this up beforehand, I'll run the bisect later this evening and let you know which build is the culprit.

I've downloaded and am running it.

Thanks Chase for running the bisect ,assign me as an owner for any further debugging.

So, after a bit of trouble getting this running, I found the version where it broke using the bisect-builds.py on a 32 bit VM (Ubuntu).

The output of the command is at the bottom, but first the actual result and some notes on how to get this running:
It's a change that happened between 303906 and 303918 and bisect-builds.py helpfully links to the changelog:   https://chromium.googlesource.com/chromium/src/+log/aa5f0b393ebc4d3d122525f11e1fcd16edbf3927..4ae87941c77264d9271afdf939381962c4f45bd2

What it took to make this work:
Download the script from https://crbug.com/chromium/456222#c76
chmod +x the script
If running on 64 bit Ubuntu (maybe others) cd /lib/x86_64-linux-gnu/ && ln -s libudev.so.1 libudev.so.0
cd back to wherever you have the bisect-builds.py
run it: ./bisect-builds.py -a linux64
On 32 bit Unbuntu I did ./bisect-builds.py -a linux
Have another terminal open and in the same directory.  It will download some stuff and then say it's trying a revision.   Then in the        other window, unzip the file that starts with that revision number (e.g. unzip 303906-chrome-linux.zip)
Then run chrome with disable-setuid-sandbox like this:  ./chrome-linux/chrome --disable-setuid-sandbox
Chrome should then run and you can test the functionality.   When you have determined if it is working or not, close chrome, go back to the window that yo uare running bisect-builds.py in and answer either good or bad as appropriate.  It will then give you a new version to try, so unzip and run that version.   Rinse and repeat as necessary for a high quality shine.

./bisect-builds.py -a linux
Downloading list of known revisions... (use --use-local-cache to cache and re-use the list of revisions)
Downloading revision 157942...inux/97874//
Received 49751732 of 49751732 bytes, 100.00%
Bisecting range [15734 (good), 321192 (bad)].
Trying revision 157942...
Revision 157942 is [(g)ood/(b)ad/(r)etry/(u)nknown/(q)uit]: g
Downloading revision 238082...
Bisecting range [157942 (good), 321192 (bad)].
Trying revision 238082...
Revision 238082 is [(g)ood/(b)ad/(r)etry/(u)nknown/(q)uit]: g
Downloading revision 291621...
Bisecting range [238082 (good), 321192 (bad)].
Trying revision 291621...
Revision 291621 is [(g)ood/(b)ad/(r)etry/(u)nknown/(q)uit]: g
Downloading revision 308060...
Bisecting range [291621 (good), 321192 (bad)].
Trying revision 308060...
Revision 308060 is [(g)ood/(b)ad/(r)etry/(u)nknown/(q)uit]: b
Downloading revision 299656...
Bisecting range [291621 (good), 308060 (bad)].
Trying revision 299656...
Revision 299656 is [(g)ood/(b)ad/(r)etry/(u)nknown/(q)uit]: g
Downloading revision 303830...
Bisecting range [299656 (good), 308060 (bad)].
Trying revision 303830...
Revision 303830 is [(g)ood/(b)ad/(r)etry/(u)nknown/(q)uit]: g
Downloading revision 305961...
Bisecting range [303830 (good), 308060 (bad)].
Trying revision 305961...
Revision 305961 is [(g)ood/(b)ad/(r)etry/(u)nknown/(q)uit]: b
Downloading revision 304821...
Bisecting range [303830 (good), 305961 (bad)].
Trying revision 304821...
Revision 304821 is [(g)ood/(b)ad/(r)etry/(u)nknown/(q)uit]: b
Downloading revision 304366...
Bisecting range [303830 (good), 304821 (bad)].
Trying revision 304366...
Revision 304366 is [(g)ood/(b)ad/(r)etry/(u)nknown/(q)uit]: b
Downloading revision 304131...
Received 84264509 of 84264509 bytes, 100.00%
Bisecting range [303830 (good), 304366 (bad)].
Trying revision 304131...
Revision 304131 is [(g)ood/(b)ad/(r)etry/(u)nknown/(q)uit]: b
Downloading revision 304001...
Bisecting range [303830 (good), 304131 (bad)].
Trying revision 304001...
Revision 304001 is [(g)ood/(b)ad/(r)etry/(u)nknown/(q)uit]: b
Downloading revision 303918...
Bisecting range [303830 (good), 304001 (bad)].
Trying revision 303918...
Revision 303918 is [(g)ood/(b)ad/(r)etry/(u)nknown/(q)uit]: b
Downloading revision 303852...
Bisecting range [303830 (good), 303918 (bad)].
Trying revision 303852...
Revision 303852 is [(g)ood/(b)ad/(r)etry/(u)nknown/(q)uit]: g
Downloading revision 303876...
Bisecting range [303852 (good), 303918 (bad)].
Trying revision 303876...
Revision 303876 is [(g)ood/(b)ad/(r)etry/(u)nknown/(q)uit]: g
Downloading revision 303894...
Bisecting range [303876 (good), 303918 (bad)].
Trying revision 303894...
Revision 303894 is [(g)ood/(b)ad/(r)etry/(u)nknown/(q)uit]: g
Downloading revision 303906...
Bisecting range [303894 (good), 303918 (bad)].
Trying revision 303906...
Revision 303906 is [(g)ood/(b)ad/(r)etry/(u)nknown/(q)uit]: g
You are probably looking for a change made after 303906 (known good), but no later than 303918 (first known bad).
NOTE: There is a Blink roll in the range, you might also want to do a Blink bisect.
CHANGELOG URL:
  https://chromium.googlesource.com/chromium/src/+log/aa5f0b393ebc4d3d122525f11e1fcd16edbf3927..4ae87941c77264d9271afdf939381962c4f45bd2

I'm suspecting this change: https://codereview.chromium.org/706763003/ "x11: Always require XI2.2 for X11"

Sadrul, could you take a look?

From what I can see locally, looks like chrome thinks the mouse-device is a touch-device. For example, I can click+drag vertically to scroll a page. Surely enough, 'xinput list' shows the mouse-device as a 'VirtualBox USB Tablet' device. If I add '--touch-devices=123' command-line flag when launching chromium-browser, the mouse starts working correctly for me.

Can anyone else confirm if this is the same behaviour and 'xinput list' output they see as well?

I had the impression that chrome was behaving like the chrome for android.

Adding '--touch-devices=123' fixes all the issues I had, nice to have this
workaround in the meantime!

Here is my xinput list (also my pc has indeed a touch screen which works to
click in my virtualbox screen).

⎡ Virtual core pointer                        id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                  id=4    [slave  pointer
(2)]
⎜   ↳ VirtualBox mouse integration                id=9    [slave  pointer
(2)]
⎜   ↳ VirtualBox USB Tablet                       id=10    [slave  pointer
(2)]
⎜   ↳ ImExPS/2 Generic Explorer Mouse             id=12    [slave  pointer
(2)]
⎣ Virtual core keyboard                       id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard                 id=5    [slave  keyboard
(3)]
    ↳ Power Button                                id=6    [slave  keyboard
(3)]
    ↳ Sleep Button                                id=7    [slave  keyboard
(3)]
    ↳ Video Bus                                   id=8    [slave  keyboard
(3)]
    ↳ AT Translated Set 2 keyboard                id=11    [slave  keyboard
(3)]

I just tested Chrome with the `--touch-devices=123` flag and it is still showing the same broken behaviour. Another user should confirm.

Chrome: 41.0.2272.89 (64-bit)
Guest: Ubuntu 14.10
VirtualBox: 4.3.26 r98988

VirtualBox I think defaults the pointing device to USB Tablet, but changing it to PS/2 mouse did not solve the issue.

--amend

Google chrome was living in the background. After killing it and relaunching with the `--touch-devices=123` did resolve the issue

[Comment Deleted]

That's unfortunate, since if X11 is lying about the device type (as it seems to be doing here), then there's not a lot chrome can do about it, especially now that chrome is going to have proper touchscreen support on linux. It may be possible for chrome to detect that the info it's getting from X11 is incorrect ... investigating farther.

That is a good workaround for me too.

My xinput list is below:

xinput list
⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ VirtualBox mouse integration              id=9    [slave  pointer  (2)]
⎜   ↳ VirtualBox USB Tablet                     id=10   [slave  pointer  (2)]
⎜   ↳ ImExPS/2 Generic Explorer Mouse           id=12   [slave  pointer  (2)]
⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]
    ↳ Sleep Button                              id=7    [slave  keyboard (3)]
    ↳ Video Bus                                 id=8    [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=11   [slave  keyboard (3)]

--touch-devices=123 worked for me, too. Is this due to a recent change with X11?

Command line arg worked for me as well with Chrome 41.0.2272.89. Chiming in since I'm running this in VMWare Player and having the same issues with mouse.

$ xinput
⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ VMware VMware Virtual USB Mouse           id=7    [slave  pointer  (2)]
⎜   ↳ VMware VMware Virtual USB Mouse           id=8    [slave  pointer  (2)]
⎜   ↳ ImPS/2 Generic Wheel Mouse                id=10   [slave  pointer  (2)]
⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=9    [slave  keyboard (3)]

[Comment Deleted]

Identical output for "xinput list" as https://crbug.com/chromium/456222#c89.
I run VirtualBox on a Windows 8.1 host on a Dell laptop that has touch screen, but most of the time I use a non-touch external monitor. Like now.

Just a thought, maybe you can add an override to the automagic detection as a user-accessible option in settings.

For the sake of completeness, I have just tested Chrome in a Windows VM, and all was working well. So this is a Linux exclusive issue.

Chrome: 41.0.2272.89 (64-bit)
Guest: Windows 8 (64-bit)
VirtualBox: 4.3.26 r98988
Host: Windows 8.1 (64-bit)

I'm not sure the blame is squarely on X11.  X11 is telling the same "bad info" to Firefox and Firefox is working fine.

Perhaps Firefox isn't trying to be touch screen friendly?

Here is my xinput list output which doesn't have the tablet reference but I still experience the loss of mouse functionality on Chrome Version 41.0.2272.89 (64-bit). Adding the --touch-devices=123 fixes the issue as a workaround. Also, I was able to fix the issue by downgrading Chrome to Version 40.0.2214.115 (64-bit).

? Virtual core pointer                          id=2    [master pointer  (3)]
?   ? Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
?   ? ImExPS/2 Generic Explorer Mouse           id=10   [slave  pointer  (2)]
?   ? VirtualBox mouse integration              id=11   [slave  pointer  (2)]
? Virtual core keyboard                         id=3    [master keyboard (2)]
    ? Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ? AT Translated Set 2 keyboard              id=6    [slave  keyboard (3)]
    ? Video Bus                                 id=7    [slave  keyboard (3)]
    ? Sleep Button                              id=8    [slave  keyboard (3)]
    ? Power Button                              id=9    [slave  keyboard (3)]

Can confirm the `--touch-devices=123` argument fixes the issue for me as well
my xinput list below

⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ VirtualBox mouse integration              id=9    [slave  pointer  (2)]
⎜   ↳ VirtualBox USB Tablet                     id=10   [slave  pointer  (2)]
⎜   ↳ ImExPS/2 Generic Explorer Mouse           id=12   [slave  pointer  (2)]
⎣ Virtual core keyboard                         id=3    [master keyboard (2)]
    ↳ Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ↳ Power Button                              id=6    [slave  keyboard (3)]
    ↳ Sleep Button                              id=7    [slave  keyboard (3)]
    ↳ Video Bus                                 id=8    [slave  keyboard (3)]
    ↳ AT Translated Set 2 keyboard              id=11   [slave  keyboard (3)]

I can confirm '--touch-devices=123' arg fixes the issue for me.

[Empty comment from Monorail migration]

The workaround seems to work for me, as well.

And here the workaround also works (Mint 17.1 on Windows Host, VirtualBox 4.3.26 r98988)!

#84 fix also works with chromium

edit
  /usr/share/applications/chromium-browser.desktop

and change the Exec-statement to
  Exec=chromium-browser %U --touch-devices=123

 

[Comment Deleted]

[Empty comment from Monorail migration]

#102 > Excellent fix, thanks a lot.

I do not think this should block a release.

Why not? This completely breaks the browser on a major platform.

This should absolutely block a release. This issue renders Chrome unusable.

As explained earlier, this seems to be an issue with the platform, where it reports the mouse-device as a touch-device. There isn't an easy way to determine when/whether the platform is misrepresenting the system to chrome, and so there isn't an easy fix. The workaround is to override the set of touch-devices chrome recognizes with the --touch-devices flag.

This absolutely should block a release. It renders all web applications useless when operating in a virtualized environment. Also, this was the output from my xinput list and you can see the mouse is not being misrepresented but I still have the same issue.

? Virtual core pointer                          id=2    [master pointer  (3)]
?   ? Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
?   ? ImExPS/2 Generic Explorer Mouse           id=10   [slave  pointer  (2)]
?   ? VirtualBox mouse integration              id=11   [slave  pointer  (2)]
? Virtual core keyboard                         id=3    [master keyboard (2)]
    ? Virtual core XTEST keyboard               id=5    [slave  keyboard (3)]
    ? AT Translated Set 2 keyboard              id=6    [slave  keyboard (3)]
    ? Video Bus                                 id=7    [slave  keyboard (3)]
    ? Sleep Button                              id=8    [slave  keyboard (3)]
    ? Power Button                              id=9    [slave  keyboard (3)]

#115: Does using --touch-devices=123 fix the issue for you?

Ah, I notice from https://crbug.com/chromium/456222#c96 that it does. So this is the same issue (the device name does not necessarily include touch/tablet etc, but the info chrome receives in response to the system queries (XIQueryDevice() etc.) tells chrome that the device has touch capability.

It would be possible to try out some workarounds in the code instead of requiring the work-around flag and see how well they work, but that would need some testing, and is not something we should backport to earlier releases.

Yes it works as a temporary workaround for a single client. Unfortunately, it is not a good workaround for a large scale virtualized environment. Especially one that we may not necessarily have control over.  

Is this a bug that should be reported to Ubuntu or Debian folks?

Sorry, meant the apparent bug of XIQueryDevice() returning bogus information.

It's more likely an issue with the device-driver used on virualbox, not sure whether ubuntu/debian or virtualbox owns that.

It's possible. However, there are reports of this same issue with VMWare and when using Synergy. It does only seem to be related to virtualized Linux environments though. I'm using Oracle Enterprise Linux.

Just opened a ticket: https://www.virtualbox.org/ticket/13984

Just a little more information. In addition to seeing this in VirtualBox we are also seeing this issue in environments that use App-V (Microsoft Application Virtualization). I have not been able to test if using the --touch-devices argument will fix the issue there as it is an environment we don't really have control over.

[Empty comment from Monorail migration]

This is present with vmware ws 11 on windows 7 x64, ubuntu 14.04 x64 guest, when vusb mouse is enabled

by default (vusb disabled) there is no problem, xinput list shows:

⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ VMware VMware Virtual USB Mouse           id=7    [slave  pointer  (2)]
⎜   ↳ ImPS/2 Generic Wheel Mouse                id=9    [slave  pointer  (2)]

vusb is needed to get extra mouse buttons to work:

mouse.vusb.enable = "TRUE"
mouse.vusb.useBasicMouse = "FALSE"

now xinput shows:

⎡ Virtual core pointer                          id=2    [master pointer  (3)]
⎜   ↳ Virtual core XTEST pointer                id=4    [slave  pointer  (2)]
⎜   ↳ VMware VMware Virtual USB Mouse           id=7    [slave  pointer  (2)]
⎜   ↳ VMware VMware Virtual USB Mouse           id=8    [slave  pointer  (2)]
⎜   ↳ ImPS/2 Generic Wheel Mouse  

and the problem manifests

if it's your contention that this is a vmware bug, please explain it to them

lanwei@ is looking into possible fixes in chrome.

I suspect the issue here is that the device is reported as a touch-device, but it sends out mouse-events. In Chrome, we convert those mouse-events into touch-events (this was necessary with earlier X versions, e.g. XI2.1, that didn't have the touch-specific events). We can probably safely stop doing this now, and that will probably fix the issues.

[Empty comment from Monorail migration]

[Empty comment from Monorail migration]

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/ad780aadaade136c6ac1711d9d0a8ebccde3d8a1

commit ad780aadaade136c6ac1711d9d0a8ebccde3d8a1
Author: lanwei <lanwei@chromium.org>
Date: Mon Mar 30 22:55:45 2015

Make the Mouse integration work in Virtualbox

XI2.2 and above include enough information in response to
XIQueryDevice to decide whether a particular device supports
touch input or not. So we remove the legacy code that is no
longer necessary.

This fixes mouse-input in virtualbox.

BUG=456222

Review URL: https://codereview.chromium.org/1047733003

Cr-Commit-Position: refs/heads/master@{#322895}

[modify] http://crrev.com/ad780aadaade136c6ac1711d9d0a8ebccde3d8a1/ui/events/devices/x11/touch_factory_x11.cc

The problem is fixed in this patch, sorry for the inconvenience.

But it looks like VirtualBox Guest Additions still has a bug, right?

solution #129 doesnt work for me

windows 8.1
latest virtualbox
ubuntu 14.4 vm
chrome 41

anyone knows when will chrome get this patch ?

Should we merge this to 42?

I would support merging the fix for 42, but we should wait a few days to make sure this isn't breaking anything (perhaps next week).

#135: Can you explain a bit more? (it's not clear if you mean the fix isn't sufficient for Virtualbox Guest Additions, or if the fix isn't included there, or something else)

#138: Even though it appears Chromium has found a different way of determining whether it is dealing with a touch device, is it true that X11 is returning bad info via XIQueryDevice()?

#139: Ah, yes. Turns out, XIQueryDevice is returning the right info, but XListInputDevices is returning bad data, claiming the mouse-device is a touchscreen (XDeviceInfo::type == XI_TOUCHSCREEN).

Thanks. Will this be a VirtualBox Guest Additions bug?

I confirmed with Sadrul, it is a VirtualBox's bug, because its old API (XListInputDevices) returns us the wrong information about the mouse.

So, does someone need to report this bug to Virtualbox? By the way, I just
updated Chrome to 41.0.2272.118 and the touch-devices workaround no longer
works. Looks like I'll have to downgrade again.

You'll have to reapply the fix #102 as the upgrade overwrote the file.

Please note that the --touch-devices flag is a workaround, and not a proper fix. You wouldn't want to use it as a long-term solution, since it may have unexpected side-effects (e.g. disable real touchscreens when using with virtualbox etc.).

Yes, meant workaround, it's definitely no fix.
There is a related ticket on the VB bugtracker: https://www.virtualbox.org/ticket/13968 and probably a couple more.

1. Does the fix apply to vmware as well?
2. What version of Chrome will get it?

https://crbug.com/chromium/456222#c104 works fine for me for Chromium on 3 VMs, thank you!
Host: Xubuntu 14.04 x64
VirtualBox: 4.3.26
VM: Xubuntu 14.04 x64, Xubuntu 14.04 x32

I ran into this problem with a Windows 8.1 host and arch linux guest.  The --touch-devices=123 workaround was effective, but chromium still froze when I tried to to for a pop-out devtools window.  I ended up having to run with the --app flag to get the separate window.

According to the thread on the virtualbox forum this might still be an issue with Chrome. Guess we have to wait for release 43 since this wasn't fixed in release 42.

https://www.virtualbox.org/ticket/13984

Yep, I can confirm that work-around works, but still not fixed in release 42.

For the workaround, you can put the flag in /etc/chromium/default

When the flag is placed in the .desktop file it can cause some funky behavior when chromium decides to spawn a new window and the flag can disappear when overwritten during a minor version change.

As per #156 I I added the CHROMIUM_FLAGS line to include --touch-devices=123 - Works in Mint 17.

CHROMIUM_FLAGS="--touch-devices=123"

[Comment Deleted]

[Comment Deleted]

Well...  As of version 42 the problem still exists AND they've deprecated the /etc/chromium/default file.

Here's where it goes now:

'If you need to pass extra command-line arguments to Chromium, you can put them in a "chromium-flags.conf" file under $HOME/.config/ (or $XDG_CONFIG_HOME). Arguments are split on whitespace and shell quoting rules apply but no further parsing is performed.'

Just put the flags in the file without anything else just like you were putting them at the end of the command.  So, for example, to put this workaround into effect put

--touch-devices=123

in a that file by itself with no quotes or anything.  This works on Arch.

Re:#160; For anyone reading this, please note that the chromium-flags.conf file is only used on Arch Linux (starting with Chromium 42). It's due to the switch to a new luancher script that we use. [1]

Other distros will still use a file under /etc for passing flags to Chromium.

[1] https://github.com/foutrelis/chromium-launcher