456523 - event.explicitOriginalTarget not populated consistently for onBlur event

Status: RESOLVED INVALID

(Firefox :: General, defect)

Description

[Ed]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.9.0.1) Gecko/2008070208 Firefox/3.0.1

I have a sample HTML document that recreates this.  I will attach it to the issue.

It is a simple page with three Fields, each using the same Javascript function for it's onBlur event handler:

function doOnBlur(event) {
    console.log("event.target.id=%s", event.target.id);
    console.log("event.explicitOriginalTarget.id=%s", event.explicitOriginalTarget.id);
}

So, all it does is log to the console (whose output I can view using firebug).

From my understanding, for the onBlur event, event.target is the field _losing_ focus, and event.explicitOriginalTarget is the field receiving focus (what is populated in IE as document.activeElement).

If I click into field1 and tab into field2, I get what is expected in the log:

event.target.id=fieldOne
event.explicitOriginalTarget.id=fieldTwo

If I click into field1 and click into field2, I get something different:

event.target.id=fieldOne
event.explicitOriginalTarget.id=fieldOne

If I click itno field1, enter some data and tab into field2, I get 

event.target.id=fieldOne
event.explicitOriginalTarget.id=fieldOne

In these last two examples, field2 is receiving focus.

This inconsistency makes it very hard to write a onBlur event handler.  For what I need to do, I need to know

1) what field is losing focus
2) what field is gaining focus

I don't care how I get it (event.explicitOriginalTarget or document.activeElement), but FF should be able to provide this information consistently.

Reproducible: Always

Steps to Reproduce:
1.
2.
3.

Comment 1

[Ed]

Attachment: Test HTML document

Comment 2

[Neil Deakin]

> From my understanding, for the onBlur event, event.target is the field _losing_
> focus, and event.explicitOriginalTarget is the field receiving focus (what is
> populated in IE as document.activeElement).

It is not, and I'm not clear why you would think that. The field about to focused is stored in 'relatedTarget'. The DOM events spec describes this behaviour.

Comment 3

[Ed]

I thought this because it was what I observed FF doing since version 2.  And, as there was no clear documentation of how FF provided this information (none that I could find, anyways), I had to go by what I could see.

From my reading of the spec, relatedTarget is defined in the MouseEvent interface.  I will need this for both navigation by clicking and tabbing through the fields.  Can I use this with both?

Comment 4

[Neil Deakin]

Actually I was confusing this with mouseenter/mouseexit events. The relatedTarget isn't set during focus/blur events at all.

There isn't actually a means of retrieving the element about to be focused.

Comment 5

[Ed]

I had been using explicitOriginalTarget, but I now see that it's not being populated consistently between keyboard and mouse navigation.  It was probably never meant to.

If Issue# 452037 were done, that would work for me.  But, that's ranked as minor and I had thought that explicitOriginalTarget was the FF mechanism.  That's why I raised this issue.

I agree with the other issue, where it's far more useful to know what field is receiving focus rather than [body] via the activeElement property.

Comment 6

[WADA:World Anti-bad-Duping Agency]

My quick test results for "explicitOriginalTarget upon onBlur". (Fx Trunk)
  ○ = explicitOriginalTarget = newly focused element
  × = explicitOriginalTarget = myslef(who loosed the focus)
(Case-1) Click
(Case-1-A) Click of other element than INPUT tpye=text/textarea,
           including text in HTML and blank area in page(BODY) 
  ○ explicitOriginalTarget = newly focused element
(Case-1-B) Click of INPUT type=text/textarea
  × explicitOriginalTarget = myslef(who loosed the focus)
(Case-2) Tab(or Shift+Tab)
(Case-2-A) Tab(or Shift+Tab), and focus switches to other element
  ○ explicitOriginalTarget = newly focused element
(Case-2-B) Tab(at last INPUT element), Shift+Tab(at first INPUT element)
  × explicitOriginalTarget = myslef(who loosed the focus)
(Case-3) Action at Menu/URL Bar/Tab Bar
(Case-3-A) Click of URL bar, Tab bar
  ○ explicitOriginalTarget = HTMLDocument (==BODY)
(Case-3-B) Help/About Minefield
  × explicitOriginalTarget = myslef(who loosed the focus)
     (Focus is back upon OK to dialog as expected. Same as alert)
(Case-3-C) Help/Help Contents(opened in new Tab in my environment)
  × explicitOriginalTarget = myslef(who loosed the focus)
     (Focus is back upon Tab click for the page as expected)
Note: In Case-2-B/Case-3-B/Case-3-C, after onBlur of the INPUT(focus looser), onBlur of HTMLDocument(==<BODY>) was observed(Window object gains focus) when <BODY onBlur="..."> is specified.

In any unexpected(except Case-1-B), it seems that HTMLDocument(BODY) is not considered as "explicitOriginalTarget" (or failed to consider, or "explicitOriginalTarget" is null then "myself" is set, ...)
When Case-1-B, phenomenon is possibly different. Blur is invoked as follows.
 1. onmoudedown at focus gainer.
 2. onBlur of focus looser
 3. onFocus of focus gainer
 4. onmouseup at focus gainer.
 5. onClick of focus gainer
At step2, focus gainer is already determined usually(eg. click of text). However, when click of INPUT type=text/textarea, more works are required before final decision of focus gainer. If it is true, phenomenon is possibly explained.

In any unexpected case, I think event.explicitOriginalTarget==myself(==focus looser) for onBlur is improper, if event.explicitOriginalTarget is used for indication of focus gainer. I think "null" is better to be set if explicit focus gainer is unknown, and when Case-3-B and Case-3-C, "unknown focus gainer" is reasonable and acceptable.

(For application development)
If event.explicitOriginalTarget is not always set as "new focus gainer", program logic shouldn't expect that event.explicitOriginalTarget is always set as focus gainer. Since event.explicitOriginalTarget can be set as myself(focus looser)  upon onBlur currently, application logic should treat it as "unknow focus gainer", and application logic has to handle "focus loose only" situation.

Please note that onBlur is for "loosing focus" and onFocus is for "getting of focus". Because "focus" event is cancelable, event.explicitOriginalTarget(which is presented to onBlur at above step2) is not always real focus gainer after the onBlur event, even when event.explicitOriginalTarget is set upon onBlur as you expect.

To Ed(bug opener):
I created modified test case based on yours, in order to see some other event object properties upon onBlur/onFocus/onClick without extension. (save data in array, and display it in new window after test). If you need this kind of test case, I'll upload for you.

Comment 7

[Neil Deakin]

explicitOriginalTarget doesn't have anything to do with focus or blur targets. The property was added only as a workaround for some drag and drop bug long ago and only pertains to mouse events. For other events, the value probably has some arbitrary value. You shouldn't be using the explicitOriginalTarget property, and you certainly shouldn't be using it if you don't know what it does.

I'm going to close this bug. There's probably a bug already filed on providing a means of knowing the element about to be focused form the blur event.