By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,644 Members | 2,082 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,644 IT Pros & Developers. It's quick & easy.

Problem tracking focus of text input elements (Mozilla?)

P: n/a

Hi all.

Hopefully this should demonstrate the problem I'm having:

http://flooble.net/~pete/focus-problem-demo/

(I'm testing it in Mozilla only, but I'm not sure if it's actually a
Mozilla-only problem)

I'm capturing the focus and blur events for the document, updating a
global Javascript variable to keep track of the "currently focussed"
element.

The problem is that it just doesn't seem to work for text (or
textarea) input elements. Just about anything else, no problem, but
not text or textarea.

You can see by switching focus (eg. by tabbing) through the five input
elements. Entering/leaving the button, checkbox or select elements
generates a focus/blur event. Entering/leaving the text/textarea
elements generates absolutely nothing.

Can anyone suggest what's wrong with this picture? :) Is it a browser
bug or am I fundamentally misunderstanding something about tracking
element focus?
Any help greatly appreciated. :)

Pete.

PS. I'd just like to mention that tracking focus bugs is hell when
just about everything you do changes the focus. :)
--
http://akira.apana.org.au/~pete/
"Reader, beware: This section is highly mathematical. Well, maybe not
_highly_ mathematical, but it's got a bunch of symbols and scary-looking
formulas. You have been warned." -- sci.crypt FAQ
Jul 23 '05 #1
Share this Question
Share on Google+
2 Replies


P: n/a


Peter Wright wrote:

Hopefully this should demonstrate the problem I'm having:

http://flooble.net/~pete/focus-problem-demo/

(I'm testing it in Mozilla only, but I'm not sure if it's actually a
Mozilla-only problem)

I'm capturing the focus and blur events for the document, updating a
global Javascript variable to keep track of the "currently focussed"
element.

The problem is that it just doesn't seem to work for text (or
textarea) input elements. Just about anything else, no problem, but
not text or textarea.


If you look at the W3C DOM Events specification here
<http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents>
then it says about the focus event:

focus
The focus event occurs when an element receives focus either via a
pointing device or by tabbing navigation. This event is valid for the
following elements: LABEL, INPUT, SELECT, TEXTAREA, and BUTTON.

* Bubbles: No
* Cancelable: No
* Context Info: None

so the focus event is not supposed to bubble up the DOM tree and
therefore if you only look for focus events at the document or window
level then you are not supposed to see anything if focus is set on an
input or a textarea or a button. The event is fired on the target and
that is all that is supposed to happen. As far as I test here the focus
event is properly fired on the controls, it just doesn't bubble which it
is not supposed to do.
So the bug in Mozilla is more likely that for some controls the focus
event bubbles while it shouldn't. There are open bugs on that:
<https://bugzilla.mozilla.org/buglist.cgi?query_format=advanced&short_desc_type= allwordssubstr&short_desc=focus+event+bubbl&produc t=Core&component=DOM&component=DOM+to+Text+Convers ion&component=DOM%3A+Abstract+Schemas&component=DO M%3A+Core&component=DOM%3A+CSSOM&component=DOM%3A+ Events&component=DOM%3A+HTML&component=DOM%3A+Leve l+0&component=DOM%3A+Load+and+Save&component=DOM%3 A+Mozilla+Extensions&component=DOM%3A+Traversal-Range&component=DOM%3A+Validation&component=DOM%3A +Views+and+Formatting&component=Event+Handling&lon g_desc_type=substring&long_desc=&bug_file_loc_type =allwordssubstr&bug_file_loc=&status_whiteboard_ty pe=allwordssubstr&status_whiteboard=&keywords_type =allwords&keywords=&emailassigned_to1=1&emailtype1 =exact&email1=&emailassigned_to2=1&emailreporter2= 1&emailqa_contact2=1&emailtype2=exact&email2=&bugi dtype=include&bug_id=&votes=&chfieldfrom=&chfieldt o=Now&chfieldvalue=&cmdtype=doit&order=Reuse+same+ sort+as+last+time&field0-0-0=noop&type0-0-0=noop&value0-0-0=>


--

Martin Honnen
http://JavaScript.FAQTs.com/
Jul 23 '05 #2

P: n/a
Martin Honnen <ma*******@yahoo.de> wrote:
Peter Wright wrote:
http://flooble.net/~pete/focus-problem-demo/

(I'm testing it in Mozilla only, but I'm not sure if it's actually a
Mozilla-only problem)
[ snip ] If you look at the W3C DOM Events specification here
<http://www.w3.org/TR/DOM-Level-2-Events/events.html#Events-eventgroupings-htmlevents>
then it says about the focus event:

focus
The focus event occurs when an element receives focus either
via a pointing device or by tabbing navigation. This event is valid
for the following elements: LABEL, INPUT, SELECT, TEXTAREA, and
BUTTON.

* Bubbles: No
Ahaaaaaa...

I should really check the official DOM documentation more often.
* Cancelable: No
* Context Info: None

so the focus event is not supposed to bubble up the DOM tree and
therefore if you only look for focus events at the document or window
level then you are not supposed to see anything if focus is set on an
input or a textarea or a button.
Okay, that does help to explain things... I was going nuts with this,
assuming that it was _supposed_ to bubble. Dammit.
The event is fired on the target and that is all that is supposed to
happen. As far as I test here the focus event is properly fired on
the controls, it just doesn't bubble which it is not supposed to do.
Argh. *sigh*

I was hoping to use this technique to track the current focus - I
guess it'll only work (for some value of "work") if I specifically set
the "focus" event handler to every single element in the display.

Ah well, I guess that'll be an acceptable solution. Sort of. :)
So the bug in Mozilla is more likely that for some controls the focus
event bubbles while it shouldn't. There are open bugs on that: [ snip open bugs ]

Thanks for your help Martin, I appreciate it.
Martin Honnen
http://JavaScript.FAQTs.com/


Pete.
--
http://akira.apana.org.au/~pete/
"What is a 'broken killfile'? One that only wounds messages rather
than killing them?" -- Craig Dickson
Jul 23 '05 #3

This discussion thread is closed

Replies have been disabled for this discussion.