16271 - Tab order starts from "top" not "this" element

Status: VERIFIED WORKSFORME

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

Description

[Sean Richardson]

Summary:
The TAB key, which moves forward from one control to the next
in HTML forms in 4.x, does not do so reliably in M11
build 1999101109, and does move focus to <A> elements
as well as form controls in some cases.

Q: should this be split into two bugs?

To replicate:

(this exact sequence demonstrates all of the misbehaviors)

1.  Start Mozilla.
2.  Go to bugzilla, and start a new bug.
3.  Scroll down to Summary:
4.  Enter a few characters into the <INPUT> control.
5.  Press the TAB key.
6.  Continue typing.
7.  Observe the result: the new characters are added to
    the Summary: <INPUT>, not the Description <INPUT>
    (also, the caret disappears, but that happens other times too)
8.  Click on the <SELECT> control beside Platform:
9.  Press the TAB key twice.
10. Observe the result: the focus shifts first to the
<A> element containing "OS:" and then to the OS <SELECT>
    control.
11. Continue pressing the TAB key seven times.
12. Observe the result: the focus (and caret) moves
    through the <INPUT> controls in sequence.
    The caret will now be in the Summary: <INPUT> control.
    (Note that this should only have taken 5 keypresses)
13. Type something more into the Summary: <INPUT> control.
14. Click back up inside the Cc: <INPUT> control
15. Press the TAB key once.
16. Type a few characters.
17. Observe the result: the caret moves to the Description:
    <INPUT> control, which comes after Summary:,
    not to the URL: <INPUT> control, which comes after Cc:

The state information being manipulated here can be eliminated
to try again by clicking on the Reload button on the taskbar.


Observed:
In 7, the text appeared in the same control, after pressing TAB.
In 10, the focus moved to the next element, not the next control.
In 12, the focus moved through all succeding elements,
not just the succeeding controls,
In 17, the text typed after pressing the TAB key did not appear
in the control following the control where the most recently entered text
was.

Note also that the tab-sequence state disappears if focus is shifted
to any other window in the NT GUI and then returned to the Mozilla
browser window.
(Q: should this be a separate bug?)

The problem observed in step 7 has been seen in other
forms, including the bugzilla login form and forms at
slashdot.org and nytimes.com.

Expected:
In 7, the added text should have appeared in the next field
(Description).
In 10, the focus should have shifted to the <SELECT> control,
not to the element in between.
In 12, the focus should move from control to control, and not
fall on any other elements.
In 17, the added text should have appeared in the next field
(URL:) not the one after the one last reached by keypresses (Description).

The tab-sequence state should persist when the browser window loses focus.


Version:
M11 build 1999101109, on WinNT

There is a chance that this is only a keypress/keycode event handler problem.
Plenty of those still remain and show themselves while entering data into the
enter_bug.cgi form.

Comment 1

[karnaze (gone)]

Eric, please reassign if appropriate.

Comment 2

[cpratt]

All of this sounds as if it's already known by us... thanks though...

Comment 3

[Eric Pollmann]

Tom, it seems that the logical "next" element to receive focus is not always the
next one to get focus, pressing tab always starts tabbing from the top of the
document.

i.e, if at step 7) in this bug description, you keep pressing the tab key, you
will notice that what really happened is that the first time it was pressed, the
top level window got focus, then it starts cycling through the elements
correctly.

Also, the behaviour at step 12 is really interesting, it's like the focus
manager still thinks that the Summary input has focus, maybe?


Reassigning to you as you are the guru of the tab manager.  :)

Comment 4

[Sean Richardson]

It looks like the behaviours noted in step 10 and 12 are correct, and should be
expected. Both <A> and <SELECT> support the TABINDEX attribute as IMPLIED,
and since none of the <A> or <SELECT> elements in enter_bug.cgi's form
have a value for TABINDEX, they should receive tabbing focus in
stream order.

So says http://www.w3.org/TR/REC-html40/interact/forms.html#adef-tabindex

Also, I think pollamn probably is referring to step 17 as
"really interesting" - it is the weird one.

Comment 5

[Eric Pollmann]

This bug doesn't seem to be present any more.  I went through all of the steps
and the only deviations from what should have happened were:

Step 12: We take seven tab presses instead of five to move down to the summary
input element.  This is not a bug, as we are including <A> elements in the
tabbing sequence.  Thus the two labels that are links (Severity and Assigned To)
are included, bringing the number of tabbable elements from five up to seven.

The caret is not updated correctly.  This is bug 8014.

The selection border is not removed when focus leaves an element.  This is bug
20322.

Since this was such a broad bug and all parts seem to be working now (except
those covered in other bugs), I'm just going to mark this WORKSFORME.  Thanks!

Comment 6

[cpratt]

OK

Comment 7

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/5e7d783f5fa5
[fenix] For https://github.com/mozilla-mobile/fenix/issues/16271 - Fixes ripple being cut-off in Saved logins sort toolbar (https://github.com/mozilla-mobile/fenix/pull/16741)