Issue metadata
Sign in to add a comment
|
The accesskey attribute should have an effect on all elements |
||||||||||||||||||||||
Issue descriptionChrome Version: 70.0.3521.2 (Official Build) dev (64-bit) OS: Linux What steps will reproduce the problem? (1) load the attached testcase (2) type the accesskey "a" (Alt+a on Linux (or Shift+Alt+a after bug 103451 is fixed)) (3) What is the expected result? A blue outline should appear. What happens instead? Nothing. The HTML spec says: "An element that has an assigned access key defines a command." https://html.spec.whatwg.org/multipage/interactive-elements.html#using-the-accesskey-attribute-to-define-a-command-on-other-elements so the steps it specifies there should be run. The element in the testcase is focusable so it should receive focus the accesskey is typed. Fwiw, the testcase works fine in Firefox on Linux (using Shift+Alt+a).
,
Sep 1
Can I work on this? It's a GoodFirstBug.
,
Sep 17
#2 michal: Are you still working on this? Otherwise I can pick this up. No rush though.
,
Nov 14
Ok, I am picking this up.
,
Dec 27
Does someone still working on this? or I would like to pick this issue. :)
,
Dec 27
This CL refers to this issue and is a WIP: https://chromium-review.googlesource.com/c/chromium/src/+/1352647 |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by tkent@chromium.org
, Aug 30Labels: Hotlist-GoodFirstBug
Status: Available (was: Untriaged)
Yeah, we should add "focusing steps" to HTMLElement::AccessKeyAction(). Spec: > 1. Run the focusing steps for the element. > 2. Fire a click event at the element. Current implementation: void HTMLElement::AccessKeyAction(bool send_mouse_events) { DispatchSimulatedClick( nullptr, send_mouse_events ? kSendMouseUpDownEvents : kSendNoEvents); }