New issue
Advanced search Search tips

Issue 664120 link

Starred by 1 user

Issue metadata

Status: Verified
Owner:
Closed: Apr 2017
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 3
Type: Bug
Team-Accessibility



Sign in to add a comment

Sticky keys do not apply command when clicking on links

Project Member Reported by sfiera@chromium.org, Nov 10 2016

Issue description

Version: 54.0.2840.71, 56.0.2908.0 checked
OS: Mac OS X 10.12.1

What steps will reproduce the problem?
(1) Enable Sticky Keys in System Preferences (Accessibility > Keyboard)
(2) Navigate to a webpage, e.g. https://en.wikipedia.org/wiki/Sticky_keys
(3) Tap command (and release), enabling it for the next interaction
(4) Click on a link

What is the expected result?
- The link opens in a new tab (command-click)

What happens instead?
- The link opens in the current tab (regular click)
- If visual feedback is enabled, the indicator still goes away, indicating that the command key was applied to the previous action, though it wasn't.


Note that while tapping command once doesn't trigger a command click, tapping command twice will result in all clicks being command-clicks until it is tapped a third time.


A brief survey of how some other contexts handle command-tap-clicks:
- Chrome *does* let you command-tap-click to highlight multiple options in a <select> element [1]
- Safari does *not* let you command-tap-click links (same as Chrome)
- iTerm2 does *not* let you command-tap-click links
- The Finder *does* let you command-tap-click to select multiple files
- The system *does* let you command-tap-click in an inactive window without raising it

[1] http://html.com/attributes/select-multiple/
 

Comment 1 by tapted@chromium.org, Nov 16 2016

Owner: ellyjo...@chromium.org
Status: Assigned (was: Untriaged)
[mac triage]

Comment 2 by sfiera@chromium.org, Jan 30 2017

Since I happen to be on a Chromebook at the moment, let me add:
- ChromeOS *does* let you ctrl-tap-click links

So ChromeOS has the expected [by me] behavior.
This works for me with trunk and with 56.0.2924.87 on 10.12.4 beta. I wonder if this was a 10.12 bug that was fixed recently? I have a look at the involved code on the Chromium side and I do not see how it could be incorrect.
I am using Canary 58.0.3005.2 on 10.12.2 and I still see the bug. I'll update to 10.12.3 and see how it goes.
Okay, thank you for investigating :)

Comment 6 by sfiera@chromium.org, Mar 10 2017

I still see the issue on 10.12.3; I'm not set up to get the beta. If it works for you, though, then you can close this out. The repro instructions seem simple enough that if it works for you it's probably fixed.
Labels: NewComponent-Accessibility NewComponent-Accessibility-Browser

Comment 8 by sfiera@chromium.org, Apr 18 2017

Status: Verified (was: Assigned)
Updated to 10.12.4; the issue is gone. Looks like this was an OS bug, rather than Chromium.

Sign in to add a comment