22741 - Tab key does not move cursor to next form field

Status: VERIFIED DUPLICATE of bug 8014

(Core :: XUL, defect, P3)

Description

[Seth Morrell]

With M12, the tab key does not move the cursor to the next available form field.
 The Tab key will move between buttons.

Environment: Win95C, Compaq Deskpro EN w/ ATI Rage Pro, proxy connection

Comment 1

[Sean Richardson]

On a current build, TAB *is* moving focus to the next form field or other
element for which tabbing navigation is valid -- but it can be hard to tell.

A bugzilla show_bug.cgi page, like this one, is an easy place to see this.
There are two problem that can make it look like nothing useful is happening.

First, if there is an <A> element in between two form elements, a TAB from the
first will go to the <A>, then another TAB will go to the next form element.
This can be tested here, easily, and is by design to match the HTML 4 spec.

Second, when the focus arrives at the next form element, a caret is not always
rendered, so it isn't possible to tell that the focus *is* there without typing
something. This is bug 8014 "[FEATURE][PP] Can't tab caret between form text
fields.", P1, M13.

Also, sometimes it takes more than one click to get focus to the *first* form
element... and until that has happened, tabbing isn't going to start from there.

The lack of feedback is a real problem. Marking as a DUP of bug 8014.

Tested with:
2000-01-05-08-M13 nightly binary on Windows NT 4.0sp3.
2000-01-06-08-M13 nightly binary on Windows NT 4.0sp3.

Note: the bug 8014 problem was easy to reproduce, but on other attempts
the caret is displaying properly, is leaving ghosts behind, or is
flashing is multiple fields, even!

Leaving ghosts behind: upon arriving in an editfield, the caret flashes exactly
once, then shows as a blue bar that stays solid, and remains solid even after
TABbing away. When right beside the border of the editfield, it can be hard to
see. If anything is typed before TABbing away, the ghost becomes a regular
flashing caret again. This may be a new bug, but more likely it means that the
existing fix for bug 8014 is not yet perfect.

When it is working properly there is no sign of the bug, but it does not always
work properly.


*** This bug has been marked as a duplicate of 8014 ***

Comment 2

[Claudius Gayle]

VERIFIED dupe

Comment 3

[Pulsebot]

Pushed by ffxbld-merge:
https://hg.mozilla.org/releases/mozilla-beta/rev/1789a67cee5b
[fenix] For https://github.com/mozilla-mobile/fenix/issues/22741 - Remove all unused strings marked moz:removedIn <= 94