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

Description Domenic Denicola 2019-06-10 14:12:41 PDT

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.

Comment 1 Radar WebKit Bug Importer 2019-06-11 00:57:36 PDT

<rdar://problem/51614064>

Comment 2 Domenic Denicola 2019-06-11 09:15:38 PDT

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!