Last Comment Bug 396927 - Implement the DOMFocusIn and DOMFocusOut events
: Implement the DOMFocusIn and DOMFocusOut events
Status: RESOLVED INVALID
:
Product: Core
Classification: Components
Component: DOM: Events (show other bugs)
: unspecified
: All All
: -- enhancement with 3 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Andrew Overholt [:overholt]
Mentors:
: 689859 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2007-09-20 10:12 PDT by Simon Pieters
Modified: 2011-09-28 01:59 PDT (History)
10 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Simon Pieters 2007-09-20 10:12:15 PDT
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.
Comment 1 Ben Hollis 2008-03-26 16:53:35 PDT
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.
Comment 2 Olli Pettay [:smaug] 2008-03-27 02:44:18 PDT
(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)
Comment 3 Juriy "kangax" Zaytsev 2009-09-13 13:56:19 PDT
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)
Comment 4 Olli Pettay [:smaug] 2009-09-13 14:02:37 PDT
(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)
Comment 5 Juriy "kangax" Zaytsev 2009-09-13 14:16:57 PDT
(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?
Comment 6 Olli Pettay [:smaug] 2009-09-13 14:26:02 PDT
focusin fires before the element takes the focus.
Similarly focusout fires just before focus moves to another element.
Comment 7 Simon Pieters 2009-09-14 01:02:10 PDT
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.
Comment 8 Juriy "kangax" Zaytsev 2009-09-14 06:02:13 PDT
(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.
Comment 9 Anne (:annevk) 2009-09-14 06:22:36 PDT
Using the capture phase should work fine in all non-IE browsers.
Comment 10 Olli Pettay [:smaug] 2009-09-14 06:34:11 PDT
(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
Comment 11 Juriy "kangax" Zaytsev 2009-09-16 08:54:37 PDT
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.
Comment 12 Angelo Borsotti 2010-11-03 03:08:55 PDT
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).
Comment 13 Simon Pieters 2011-06-08 11:38:50 PDT
These events are deprecated in DOM3 Events.
Comment 14 Josh Matthews [:jdm] (on vacation until Dec 5) 2011-09-27 23:46:37 PDT
*** Bug 689859 has been marked as a duplicate of this bug. ***
Comment 15 Angelo Borsotti 2011-09-28 01:55:13 PDT
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.
Comment 16 Olli Pettay [:smaug] 2011-09-28 01:59:47 PDT
There is Bug 687787.
Feel free to fix it (or I'll do once I've fixed few other bugs).

Note You need to log in before you can comment on or make changes to this bug.