New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 659859 link

Starred by 2 users

Issue metadata

Status: Untriaged
Owner: ----
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Chrome
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Madcatz RAT3 breaks mouse-cursor auto-hide/re-show when text is typed on the keyboard, stops trackpad working, and can't interact with tab-strip

Project Member Reported by w...@chromium.org, Oct 27 2016

Issue description

Version: 55.0.2883.17
OS: ChromeOS (Flip)

What steps will reproduce the problem?

(without a mouse connected)
(1) Open a tab.
(2) Type something into the URL bar.
(3) Move the cursor, using the trackpad.

(4) Connect an external (USB) mouse.
(5) Type something into the URL bar.
(6) Move the cursor using the mouse.
(7) Type something into the URL bar.
(8) Move the cursor using the trackpad.

What is the expected output?

Expect that the mouse cursor auto-hides at (2), (5) and (7).
Expect that the mouse cursor becomes visible again at (3), (6) and (8).

What do you see instead?

At (6) and (8) the mouse cursor does not become visible - i.e. this behaviours depends on whether an external mouse is connected, not on whether it is actually the input device used to move the cursor.

The mouse cursor will only become visible again if the trackpad or external mouse are actually used to click somewhere.
 

Comment 1 by w...@chromium.org, Nov 20 2016

Cc: dtapu...@chromium.org gkihumba@chromium.org
Labels: -M-55 M-56
Summary: External mouse breaks mouse-cursor auto-hide/re-show when text is typed on the keyboard, and tab-switching via mouse (was: External mouse breaks mouse-cursor auto-hide/re-show when text is typed on the keyboard)
+gkihumba, dtapuska: tl;dr: Simply connecting an external USB mouse seems to break cursor input to ChromeOS in various ways, making the external mouse more-or-less unusable with ChromeOS in practice.
Cc: osh...@chromium.org adlr@chromium.org
Owner: afakhry@chromium.org
Status: Assigned (was: Untriaged)
I'm unable to repro this on today's ToT 57.0.2937.0 (link).
wez@ Do you still see this issue?

Comment 4 by w...@chromium.org, Dec 1 2016

I was still able to repro this with dev-channel (M56.0.2924.9, I believe) on Minnie. My mouse is a RAT 3; maybe a device-specific issue?
Cc: dhadd...@chromium.org dchan@chromium.org
dhaddock@, dchan@ do you see this issue on other boards?
Cc: ka...@chromium.org
Kalin, can your team repro this?
Cc: afakhry@chromium.org
Owner: weidongg@chromium.org
I cannot repro this on Version 55.0.2883.17 Platform 8872.15.0 (link).
Is this possible a device specific or the certain mouse issue? Could you change a mouse to try it again? wez@

Comment 10 by w...@chromium.org, Apr 26 2017

Re #9: Very astute! I've just tried this with a Targus AMU1602EU, and then with a Madcatz RAT3 - the Targus works fine but the RAT3 exhibits these issues:

1. Moving mouse w/ trackpad, while RAT3 connected, cursor is not visible.
2. Left & right mouse buttons on RAT3 don't work on tab-strip (middle-click does seem to work).
3. Left & right mouse buttons on RAT3 work fine on content area (i.e. left-drag selects text, right-click shows context menu).


Status: WontFix (was: Assigned)
Re #10, Thanks! It seems I could conclude this as not reproducible.

Comment 12 by w...@chromium.org, Apr 26 2017

Status: Assigned (was: WontFix)
Summary: Madcatz RAT3 breaks mouse-cursor auto-hide/re-show when text is typed on the keyboard, stops trackpad working, and can't interact with tab-strip (was: External mouse breaks mouse-cursor auto-hide/re-show when text is typed on the keyboard, and tab-switching via mouse)
Re #11: Well, I'd say it _is_ reproducible, but it's specific to certain devices - I think it would be worth understanding why these devices cause problems.

Comment 13 by adlr@chromium.org, Apr 26 2017

IIRC, madcatz mice (at least one i saw years ago), have different modes, and they communicate which mode they are in by telling the OS they are holding down some mouse button. So like holding down button 17 = game mode, holding down button 18 = docs mode, etc.

Once upon a time we put in a special patch to ignore these buttons. I will do a quick search.

Comment 14 by w...@chromium.org, Apr 26 2017

Fascinating. That could explain the fact that content-area works, but
tab-strip doesn't, if the tab-strip happens to be checking "is button X the
only button down" whereas content is responding to "button-down for button
X" (and thereby ignoring the fact that another button is also down).

Comment 15 by adlr@chromium.org, Apr 26 2017

Well, I can't find any evidence or CLs. I will say that email retention policy + moving bugs databases isn't helping here.

I will not be planning to work on this, but it someone wants to make a kernel patch, that's probably a good place for this.

Comment 16 by w...@chromium.org, Apr 27 2017

FWIW there's an article on using MadCatz devices with ArchLinux that
corroborates adlr@'s recollection:
https://wiki.archlinux.org/index.php/Mad_Catz_Mouse

Comment 17 by weidongg@chromium.org, Yesterday (29 hours ago)

Status: Untriaged (was: Assigned)
back to triage since not actively working on this.

Comment 18 by weidongg@chromium.org, Yesterday (29 hours ago)

Cc: weidongg@chromium.org
Owner: ----

Sign in to add a comment