Bug 198730
| Summary: | <area> is click and sequentially focusable, but not programatically focusable | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Domenic Denicola <d> |
| Component: | DOM | Assignee: | Nobody <webkit-unassigned> |
| Status: | RESOLVED INVALID | ||
| Severity: | Normal | CC: | cdumez, rniwa, webkit-bug-importer, wenson_hsieh |
| Priority: | P2 | Keywords: | InRadar |
| Version: | Safari Technology Preview | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Domenic Denicola
Discussed in the very long https://github.com/whatwg/html/issues/4607, but I will summarize here. rniwa@ indicated that filing an issue would be appreciated.
If you visit https://boom-bath.glitch.me/tabindex.html in Safari:
- You can tab to each <area> element in the last row, and it will become the document.activeElement.
- You can click your mouse on each <area> element in the last row, and it will become the document.activeElement.
- If you click the "click me" button in the last row, which will attempt to call .focus() on the first of the <area> elements, document.activeElement stays as the <body>.
This is a strange exception. Besides <area>, all elements that are click/sequentially focusable, are also programmatically focusable. We're contemplating (in the above-linked HTML issue tracker) making it a spec requirement, or at least recommendation. So we thought maybe Safari would like to change <area> to behave like other elements in this regard.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Radar WebKit Bug Importer
<rdar://problem/51614064>
Domenic Denicola
In the counterpart Chromium bug https://bugs.chromium.org/p/chromium/issues/detail?id=972764 we discovered that the test case was invalid. I was attempting to focus a href=""-less <area> programmatically, whereas I was clicking on a <area> that had a href="".
Sorry for the noise!