Logs are present at https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cros/686949/?debugUI=CLOUD

adlr@ this is currently beta blocking. Will you please take a look and share who the owner should be?

abodenha, can you please direct this to whoever is working on md settings?

adlr@ I think md-settings is a red-herring here. The issue is that when mouse buttons are swapped the right button isn't working correctly.

sontis@ can you be more specific about what you mean by "not working properly"

i'm unable to repro this. Sontis, can you show me in person?

adlr@ do you think this is stable blocking? Should we move the RBS label off?

I can't repro this, so I would ask sontis@

sontis@ do you still have a repro for this issue? If not I will remove the RBS label.

I am still able to reproduce this issue on build 9202.50.0

Logs are present at https://pantheon.corp.google.com/storage/browser/chromiumos-test-logs/bugfiles/cros/686949/new/?debugUI=CLOUD

Repo steps:

(1)  Sign in to the device.
(2)  Connect any USB mouse.
(3)  Go to "chrome:md-settings"
(4)  enabnle "swap the primary mouse button" using mouse.
(5)  Use mouse right button to click.



Note: This issue is specific to "chrome:md-settings" 

Albert, this does look specific to md-settings. So I'm bouncing back to you! If you think it's not md-settings specific, please do a test to confirm.

Thanks!

md-settings isn't shipping in 57 so we don't need to block on it.

sontis@ - Could you clarify this a bit more? By "Right click is not working properly", is it as though the setting is being ignored, or does the behavior change in an unexpected way?

abodenha@ - This should be a pretty straightforward bug for anyone with access to a minnie device (or other device with two mouse buttons), if there is someone MTV that has cycles. Otherwise I can see if ejcaruso@ has a device I can borrow.

@ comment 14:
Before swapping:                             after swapping:
Left click (working as left button)        Left click (working as right button)
Right click (working as right button)      Right click (Ignored)

That is.... surprising.

Could you re-confirm that the behavior is MD Settings specific?
i.e. change the setting on the same device / version using both chrome://settings-frame and chrome://md-settings.

Both pages just change a single pref: 'settings.mouse.primary_right'.

Glancing at the code, I don't see how the settings UI could put the device in a halfway state as described.

I can't reproduce this on ToT, or on the latest 57 beta (9202.50.0, Chrome 57.0.2987.94).

-> abodenha@ - I think we need to figure out how to repro this, or borrow the device in question. I can't think of anything else to try here.

sontis@ - When you re-confirm this, can you make sure to try both buttons on a variety of UI, just to ensure that it isn't some other strange behavior in MD Settings that is being exposed?

Is this specific to minnie?  I'm unable to repro in Version 57.0.2987.100 beta (64-bit) Platform 9202.51.0 (Official Build) beta-channel samus

Let me see if I can find a minnie to try with. They're in short supply around here at the moment.

sontis@ and kalin@ just came by and reproed the issue and now it makes sense.  It's a fun bit of subtlety and not platform dependent.

Updated repro steps:
1: Open md-settings
2: Open the mouse controls section
3: DO NOT simply click the "swap mouse buttons" control.  Instead, DRAG the button from left to right.
4: Left click anywhere in the window.

My theory here is that we get a L-mouse-down and start drag and then at some point during the drag operation the setting is updated; left becomes right and the drag code gets confusticated. Releasing the button now sends a r-mouse-up.

Basically, this is caused by switching the control to a radio button rather than a checkbox and applying the setting immediately.  Doing so means we end up doing "impossible" things with the mouse during the drag.

I'm able to repro on samus.

I'm borderline on calling this release blocking. It's an unlikely state to get into, but it leaves your mouse totally borked until you restart the machine.

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

commit 9b5e6ff303ed188622c81186bb86fe37e60ebb67
Author: stevenjb <stevenjb@chromium.org>
Date: Fri Mar 24 21:19:42 2017

MD Settings: Pointers: Avoid setting mouse swap pref while mouse pressed

BUG= 686949 
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2753353002
Cr-Commit-Position: refs/heads/master@{#459555}

[modify] https://crrev.com/9b5e6ff303ed188622c81186bb86fe37e60ebb67/chrome/browser/resources/settings/device_page/compiled_resources2.gyp
[modify] https://crrev.com/9b5e6ff303ed188622c81186bb86fe37e60ebb67/chrome/browser/resources/settings/device_page/pointers.html
[modify] https://crrev.com/9b5e6ff303ed188622c81186bb86fe37e60ebb67/chrome/browser/resources/settings/device_page/pointers.js

Verified on build 9408.0.0