269900 - onfocus doesn;t support setting status bar text by scripts

Status: RESOLVED DUPLICATE of bug 133874

(Core :: DOM: Events, defect)

Description

[Foteos Macrides]

User-Agent:       Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041105
Build Identifier: Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.8a5) Gecko/20041105

If the onfocus event is invoked via keyboard navigation (TAB and Shift-TAB) or a
focus() call, it does not support use of window.status= or self.status= to set
the status bar text.  Like other browsers, Mozilla supports this for the
onmouseover event, but unlike other browsers, Mozilla does not support it for
onfocus.  Similarly, the onblur event (homolog of the onmouseout event) cannot
be used in Mozilla to clear status bar text via window.status= or self.status=

Reproducible: Always
Steps to Reproduce:
1. Go to http://www.macridesweb.com/oltest/FocusProblems.html
2. Read the info labeled PROBLEM (4)
3. Follow the instructions in that document

Actual Results:  
Status bar text could not be set via onfocus or cleared via onblur

Expected Results:  
Setting or clearing of status bar text as with other browsers such as Internet
Explorer (which presently is favored by users with disabilities because of its
more complete support for keyboard navigation and associated focus and blur
scripting).

Bug 133874, Bug 236791 and Bug 268091 are related.  All are important to fix for
the benefit of users with disabilities who depend on good keyboard navigation
and focus / blur scripting support.

Comment 1

[Boris Zbarsky [:bzbarsky]]

Not likely to be an events issue... the UI has code for determining what the
source of the window.status call was, and it's likely that this code is failing...

Comment 2

[Foteos Macrides]

*** Bug 270660 has been marked as a duplicate of this bug. ***

Comment 3

[[e-mail]]

OK, so there are two parts to this bug:
a) the mouseover/focus status is not cleared on blur, only on mouseout
b) when a focus event handler resets the focus, the blur is processed first.

Comment 4

[Foteos Macrides]

(In reply to comment #3)
> OK, so there are two parts to this bug:
> a) the mouseover/focus status is not cleared on blur, only on mouseout
> b) when a focus event handler resets the focus, the blur is processed first.

Although I decided that my Bug 270660 filing should be marked as a DUP for this 
bug report, my Description and Comment there are more complete and may be worth 
reading. There are "two parts" to this bug in the sense that a status bar text 
instruction (window.status= or self.status=) in the value of an element's 
onblur attribute does not succeed, just as such an instruction does not succeed 
when in the value of the onfocus attribute, if the blur or focus event for the 
element was invoked via keyboard navigation rather than via a mouseover or 
mouseout event with scripting that included a blur() or focus() call for that 
element.

Note that status bar text instructions are unusual in that the return value for 
the overall scripting can affect whether they are acted upon, and perhaps that 
is a factor in the failures to act on such instructions when there is no mouse-
based event in a chain leading to the focus or blur event.

In the course of playing around with my testcases, it did appear to me that the 
Geckos do not act on scripting associated with a focus until after they act on 
scripting associated with any blur that the focus necessitates (e.g., in 
another element which presently has focus), whereas IE appeared to handle that 
the other way 'round.  If so, I don't know which order should be 
considered "correct" or whether that's a factor in this bug.  More generally, 
perhaps bubbling issues in the Geckos versus other browsers are a factor in 
this bug, but I couldn't reliably assess that simply from playing around with 
my particular testcases.

I'm don't adequately understand Comment #1 that this is not likely to be an 
event issue but instead may be due to a failure in UI code that determines the 
source of the status bar text instruction. Is this referring to some aspect of 
the code for the browser's "Allow scripts to change status bar text" option, 
which must be checked (and is not checked by default for Firefox, but is for 
the other Geckos)?

Comment 5

[Gervase Markham [:gerv]]

This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/

Comment 6

[[e-mail]]

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

Comment 7

[Foteos Macrides]

(In reply to comment #5)
I downloaded and tried Firefox 1.5 beta 1 for Windows.  It still has all of the 
problems described and illustrated in my test case (above) for this bug.  This 
is unfortunate given that version 1.5 is being promoted as dealing with the 
Gecko inadequacies for accessibility.