A Simple Illustrative Form for
Gecko-engine Focus Problems
Use keyboard navigation (TAB and Shift-TAB) or your mouse to grant focus to the form fields.  Hovers over the labeling anchors grant focus to their respective text input fields via javascript focus() calls.  Hovers over the Submit or Reset buttons equivalently grant focus to themselves via focus() calls.  The onfocus attributes in the two text input fields and in the two buttons have values which include status bar text instructions (self.status='foo').  Compare what is shown in the status bar when you use keyboard navigation versus mouse-based navigation with the Gecko-engine browsers (Mozilla, Firefox, Netscape6/7, etc.) versus other browsers.


(1)  When focus is granted to the text inputs or buttons via the focus() calls associated with hovering (mouseover) events, for some versions of Firefox with a bug apparently related to its autocomplete, this generates error messages in the JavaScript Console about an internal (XUL) error.  See Bug 236791This is fixed in v2.0.  You can use autocomplete="off" in the form start tag or in the individual input tags as a workaround for earlier versions with this problem.

(2)  None of the Geckos use a darker border or other indicator of the "default" Submit button when an input or other form field element has focus.  See Bug 102057.  The default is the first Submit button encountered while parsing a form block's content, but if there are multiple submit buttons for the form, the first encountered when parsing might not appear to be the first in the rendered display, and thus should have an indicator.  Also, if a document has more than one form, and multiple submit buttons for that reason, the darker border or other indicator is needed for the Submit button of the "current" form (the form in which a form field element has focus).

(3)  For all of the Geckos through Firefox v2.0, keyboard navigation to the "Bug 269900" link (below) leads to an inappropriate carry-over of its URL (resolved href) display in the status bar on forward (TAB) navigation to the address bar.  Similarly, back (Shift-TAB) keyboard navigation to the form fields from the "Bug 236791" link (above) is associated with an inappropriate carry-over of its URL display in the status bar.  A link's URL should be shown in the status bar only during the focus or mouseover events for the link, and be removed on mouseout or blur.  This is fixed in the code set which will become Firefox v3.0  See Bug 133874.

(4)  For all of the Geckos through Firefox v2.0, when using keyboard navigation the status bar text cannot be set by scripts evoked via the values of the onfocus or onblur event attributes.  This is fixed in the code set which will become Firefox v3.0  See Bug 269900.  In the case of the above form fields with the presently released versions, in conjunction with PROBLEM (3) this PROBLEM (4) means that when a form field gets focus following TABs or Shift-TABs, the status bar will continue showing the URL of the preceding anchor that had focus, because the self.status='foo' code in the onfocus attribute values of the tags for the form fields did not serve as a workaround for the Geckos' PROBLEM (3).  In contrast, if an onfocus or onblur is consequent to a focus() or blur() call invoked via a mouseover or mouseout (e.g., the focus() calls invoked via hovers over the labeling anchors or the Submit or Reset buttons, above), then the status bar text instructions (self.status='foo' code) in the onfocus or onblur attribute values of the form field tags do succeed (i.e., the bug is overridden if a mouse-based event leads a chain of events).  So well-sighted users of the mouse are OK, but unfortunately not those using keyboard navigation.