Closed Bug 396927 Opened 17 years ago Closed 13 years ago

Implement the DOMFocusIn and DOMFocusOut events

Categories

(Core :: DOM: Events, enhancement)

Product:
Core
Component:
DOM: Events
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED INVALID

People

(Reporter: zcorpan, Unassigned)

References

Details

User-Agent:       Opera/9.23 (Windows NT 5.1; U; en)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007091804 Minefield/3.0a8pre

Please implement the DOMFocusIn and DOMFocusOut events.

Opera and Safari support them.

Spec: http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-UIEvent (or http://www.w3.org/TR/DOM-Level-3-Events/events.html#Events-UIEvent )

Why they are more useful than the focus and blur events: they bubble, which makes it possible to listen for them on the document object to catch all focus changes (useful e.g. for implementing the placeholder="" attribute with js [1]) and they apply to any focussable element (useful for e.g. doing something when focussing a <canvas tabindex=0> game or something).

[1] http://simon.html5.org/sandbox/js/placeholder.js

Reproducible: Always

Steps to Reproduce:
1. Add an event listener that listens for DOMFocusIn or DOMFocusOut events
2.
3.
Actual Results:  
The events aren't dispatched

Expected Results:  
The events should be dispatched after any focus/blur events.
Now that focus and blur don't bubble like they used to in FF2 (because bug 238987 was fixed) we really need the DOMFocusIn and DOMFocusOut events.
(In reply to comment #0)
> Why they are more useful than the focus and blur events: they bubble, which
> makes it possible to listen for them on the document object to catch all focus
> changes
You can catch focus/blur changes on document, just use capturing event listener.

(Note, I'm not saying we shouldn't implemented DOMFocusIn/Out)
Didn't find dupes. Can confirm on FF 3.6a1. Marking as NEW.

quirksmode.org has an interactive test for these events (http://www.quirksmode.org/dom/events/tests/blurfocus.html)

I have an automated test in CFT (http://yura.thinkweb2.com/cft/#IS_DOMFOCUSIN_SUPPORTED)
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #0)
> Why they are more useful than the focus and blur events: they bubble, which
> makes it possible to listen for them on the document object to catch all focus
> changes
Well, for this you can use capturing event listener for focus and blur.

Note, the latest DOM 3 Events draft marks these events deprecated.
http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-DOMFocusIn
(Though, the draft has some problems there, I think. DOMFocusIn isn't like focusin, and
DOMFocusOut isn't like focusout)
(In reply to comment #4)
> (In reply to comment #0)
> > Why they are more useful than the focus and blur events: they bubble, which
> > makes it possible to listen for them on the document object to catch all focus
> > changes
> Well, for this you can use capturing event listener for focus and blur.
> 
> Note, the latest DOM 3 Events draft marks these events deprecated.
> http://dev.w3.org/2006/webapi/DOM-Level-3-Events/html/DOM3-Events.html#event-type-DOMFocusIn

Ah, thanks. I wasn't aware of it.

So would it make sense to implement focusin/focusout and perhaps alias them with DOMFocusIn/DOMFocusOut for compatibility (DOML2 is still a recommendation after all)?

> (Though, the draft has some problems there, I think. DOMFocusIn isn't like
> focusin, and
> DOMFocusOut isn't like focusout)

Could you please explain how those differ?
focusin fires before the element takes the focus.
Similarly focusout fires just before focus moves to another element.
Note that Opera might drop support for DOMFocusIn, and we don't support focusin. Having three events for the same purpose will probably just confuse authors and be a source of bugs.

I wasn't aware of how capturing works when I filed this bug.

Feel free to WONTFIX.
(In reply to comment #7)
> Note that Opera might drop support for DOMFocusIn, and we don't support
> focusin. Having three events for the same purpose will probably just confuse
> authors and be a source of bugs.

Things are already pretty confusing. 

Currently, in order to listen for focus events on a document level, one needs to use "focusin" in IE, "DOMFocusIn" in Opera and Webkit, and the capture phase in Gecko. All of these should also somehow be properly feature tested. If Opera drops "DOMFocusIn" then older versions of Opera will fall into DOMFocusIn branch and newer - into capture one. If Mozilla implements either focusin or DOMFocusIn, there will eventually be no need for 3rd (capturing) branch.
Using the capture phase should work fine in all non-IE browsers.
(In reply to comment #9)
> Using the capture phase should work fine in all non-IE browsers.
And one could just use focus and blur, no need for DOMFocusIn/Out
Following Anne's advice, I ran some tests with listeners having `useCapture` set to `true`. It does seem to work on FF 2,3,3.5; Safari 2,3,4; Opera 9.5,9.6,10 and Chrome 2.
A document capturing listener for the focus event does not have the
same behavior as the DOMFocusIn event: the former makes the handler
be executed AFTER a blur handler, while the second must make it be
executed BEFORE (see W3C Document Object Model (DOM) Level 3 Events Specification).
These events are deprecated in DOM3 Events.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → INVALID
You are right, they are now deprecated, but because there is the focusin
event.
So, if you do not want to implement DOMFocusIn, then implement focusin.
I could file a new bug for it, but to be more efficient I would suggest
to use this bug instead of closing it and opening a new one.
There is Bug 687787.
Feel free to fix it (or I'll do once I've fixed few other bugs).
You need to log in before you can comment on or make changes to this bug.