1878755 - focus tab-traversal-area isn't interoperable for image map 'area' elements

Status: ASSIGNED

(Core :: DOM: UI Events & Focus Handling, defect)

Description

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Not sure which behavior is correct/wrong here, but we seem to be the odd one out, so I figured I'd file a bug.

STR:

1. Load the attached testcase.
2. Press Tab several times and pay careful attention to the order in which things are focused.

EXPECTED RESULTS (based on Chrome/WebKit at least):
Tab traversal order should match the 1,2,3,4 numbering shown visually in the testcase -- textfield/img/textfield/textfield.
(The img's tab-index seems to be based on where the area element appears in the DOM, which is between the first and second textfields.)

ACTUAL RESULTS:
Tab traversal order does not match the numbering shown in the testcase. It goes visually from the top to the bottom: textfield/textfield/img/textfield.
(The img's tab-index seems to be based on where the img element appears in the DOM, which is between the second and third textfields.)

Chrome 123.0.6262.5 (Official Build) dev (64-bit) and gnome-web/epiphany 42.4 give EXPECTED RESULTS.
Firefox Nightly 124.0a1 (2024-02-02) (64-bit) gives ACTUAL RESULTS.

Comment 1

[Sean Feng [:sefeng]]

Also unsure about which one's correct. I am asking spec folks to clarify this. I think we should do DOM orders, and that's what Chrome and Safari do. Once this is confirmed (or I don't hear anything back), I'll write a patch for this.

Comment 2

[Sean Feng [:sefeng]]

Attachment: Bug 1878755 - Fix the focus handling for image map

Our current focus handling for image map is buggy in many ways because
even if there's separate function called GetNextTabbableMapArea, we still rely on
nsFrameIterator often. Using nsFrameIterator for image map is buggy
because the primary frame of an <area> element is the corresponding image
frame which doesn't represent the DOM tree position.

Comment 3

[Hsin-Yi Tsai (she/her) [:hsinyi]]

The bug/patch is in progress.