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

Issue 615520 link

Starred by 2 users

Issue metadata

Status: Fixed
Owner:
Closed: Jun 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Chrome
Pri: 2
Type: Bug



Sign in to add a comment

MD Ink Drop "stuck" on toolbar button if, while the space bar is held down the arrow keys select another button

Project Member Reported by kylixrd@chromium.org, May 27 2016

Issue description

Version: 53.0.2750.0
OS: Windows 8.1 & 10

What steps will reproduce the problem?
(1) Make sure at least two toolbar buttons are visible and enabled.
(2) Shift-Alt-T to select focus one of the toolbar buttons
(3) Press and hold the space bar (MD Inkdrop should be visible)
(4) While still holding down the space bar, press the right or left arrow key to select another button
(5) Release the space bar.

EXPECTED:

Ink Drop should disappear and spacebar down state should be cancelled.

ACTUAL:

Ink Drop is "stuck" on and the newly selected button is triggered instead of nothing.

Please use labels and text to provide additional information.

 
Cc: bruthig@chromium.org est...@chromium.org
Labels: M-53 Proj-MaterialDesign-NativeUI OS-Chrome OS-Linux
Owner: kylixrd@chromium.org
Status: Assigned (was: Untriaged)
I suspect this was introduced by  issue 591140 .  I think the fix should be pretty simple though, i.e. InkDropHostView::OnBlur() should animate the ripple to HIDDEN.

Allen, do you want to take a crack at this?
Yes, I was planning looking at this, but wanted to get it tracked first.
Hmm I take that back it probably wasn't caused by  issue 591140 .
Cc: dmazz...@chromium.org
When focus is shifted to another button, the Ink drop ripple isn't shown, however when the space bar is released the newly selected button's click behavior is triggered. 

This behavior should change to hiding the Ink drop ripple on the original button and releasing the space bar should do nothing on the newly selected button. IOW, the "click" notification should fire only if the button was previously "armed" in the "pressed" state.

Additionally, we can consider the use of <ESC> to also cancel the pressed or "armed" state of the button even while it remains focused. Normally, <ESC> isn't processed directly, rather a WM_CANCELMODE message is generated. This message is then processed to cancel any currently active "modes" such as an armed key press, an open popup menu, an active "in-place" editing mode, etc...

Since what I outlined above seems to be normal Windows behavior, there should be minimal impact on accessibility: Need to get agreement from dmazzoni@.
Allen, is this Fixed now?
Status: Fixed (was: Assigned)
Yes.

Sign in to add a comment