focus() / blur() problems

3 views
Skip to first unread message

Foteos Macrides

unread,
Nov 13, 2004, 10:19:57 PM11/13/04
to
I have been developing documents intended for coordinated keyboard (TAB and
Shift-TAB) or mouse navigation in relation to onfocus, onblur and onkeypress,
or onmouseover, onmouseout and onclick events. In exercising a variety of
browsers with such documents, I ran into error messages in the JavaScript
Console for Firefox 1.0 that seem inappropriate and do not occur with the
other flavors of Gecko-engine browsers.

I have created a small test document which generates the error messages in
Firefox:

http://www.macridesweb.com/oltest/FocusProblems.html

It has two labeling anchors for two text input fields, and Submit and Reset
buttons. Among other things, hovers (onmouseover) for the labeling anchors
grant focus to their respective text input fields via focus() calls.
Similarly, hovers for the buttons use focus() calls to grant focus to
themselves, Markup for the onfocus event does the equivalent with keyboard
navigation.

If one does more than one onmouseover for the labeling anchors, Firefox starts
generating elaborate error messages concerning its source. I would appreciate
any insights into what is going on there, i.e., is there a problem with my
markup, or is this a Firefox bug?

Fote
--


Martin Honnen

unread,
Nov 14, 2004, 6:55:09 AM11/14/04
to

Foteos Macrides wrote:


> http://www.macridesweb.com/oltest/FocusProblems.html
>

> If one does more than one onmouseover for the labeling anchors, Firefox starts
> generating elaborate error messages concerning its source. I would appreciate
> any insights into what is going on there, i.e., is there a problem with my
> markup, or is this a Firefox bug?

I get the following error message with Firefox 1.0:

Error: [Exception... "'Permission denied to get property
XULElement.selectedIndex' when calling method:
[nsIAutoCompletePopup::selectedIndex]" nsresult: "0x8057001e
(NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: <unknown
filename> :: onmouseover :: line 1" data: no]
Source File:
Line: 1

this doesn't seem to be an error in your code but in any XUL code that
Firefox runs.

Are you experiencing any problems with your script in the HTML page? Is
execution of your script abandoned when that error occurs? Is anything
(besides that error message) not working as intended?

--

Martin Honnen
http://JavaScript.FAQTs.com/

Foteos Macrides

unread,
Nov 14, 2004, 9:08:01 AM11/14/04
to

"Martin Honnen" <maho...@yahoo.de> wrote in message
news:cn7h36$am...@ripley.netscape.com...

That is a stripped down 'test" document and aside from the error messages on
mouseovers of the labeling anchors I see no problems with Firefox beyond ones
common to Geckos and summarized at the bottom of the document.

I normally set the status bar for mouseovers of the labeling anchors, which
are not actual links such that their href "(javascript:void(0):") is better
replaced in the status bar by informational strings. Because Firefox is
distributed with the ability to do that blocked by default, I tried checking
"Allow scripts to change status bar" in Tools | Options | Web Features |
Advanced, but that makes no apparent difference.

Although not in that test document, normally I use an imported script library
and markup in the onmouseover and onfocus event attribute values for invoking
DHTML informational popups in addition to setting the status bar strings.
Those are intended to be homologous to longdesc, but available via any element
for both sighted users and ADA users with GUI screen readers. A reasonably
"simple" test document for that is:

http://www.macridesweb.com/oltest/ONFOCUS.html

which I put up for Bugzilla Bug #268091

https://bugzilla.mozilla.org/show_bug.cgi?id=268091

concerning focus outlines. Firefox 1.0 generates the same error message
concerning its own XUL code on mouseovers for the labeling anchors after the
first. But again, aside from those messages in the JavaScript Console, I
experience no problems with those documents beyond ones common to the Geckos.

But if Firefox really has a bug in its code for handling onmouseover events, I
can't help but worry that it might in some context bite users of my documents
and/or my script library, and thus would like to get to the bottom of this
issue. I'd be happy to submit a bug report once I better understand what the
problem is with Firefox.

Fote
--


Martin Honnen

unread,
Nov 14, 2004, 9:28:03 AM11/14/04
to

Foteos Macrides wrote:


> But if Firefox really has a bug in its code for handling onmouseover events, I
> can't help but worry that it might in some context bite users of my documents
> and/or my script library, and thus would like to get to the bottom of this
> issue. I'd be happy to submit a bug report once I better understand what the
> problem is with Firefox.

Guessing from the error message

Error: [Exception... "'Permission denied to get property
XULElement.selectedIndex' when calling method:
[nsIAutoCompletePopup::selectedIndex]" nsresult: "0x8057001e
(NS_ERROR_XPC_JS_THREW_STRING)" location: "JS frame :: <unknown
filename> :: onmouseover :: line 1" data: no]
Source File:
Line: 1

some internal error (error in JavaScript in XUL) related to
autocompleting of text fields happens., Firefox has its own interfaces
for that as far as I can tell from the documentation at
http://xulplanet.com/ so it might well be something specific to Firefox.
The nsIAutoCompletePopup interface is documented here:
http://xulplanet.com/references/xpcomref/ifaces/nsIAutoCompletePopup.html
Oddly that page claims that the interface has been removed from newer
versions.

I can't really tell what the error is about, you will have to wait till
someone hacking Firefox reads this thread.

Martin Honnen

unread,
Nov 14, 2004, 10:05:48 AM11/14/04
to

Foteos Macrides wrote:


> But if Firefox really has a bug in its code for handling onmouseover events, I
> can't help but worry that it might in some context bite users of my documents
> and/or my script library, and thus would like to get to the bottom of this
> issue. I'd be happy to submit a bug report once I better understand what the
> problem is with Firefox.

There are already bugs filed on that:
https://bugzilla.mozilla.org/show_bug.cgi?id=236791
If you set
<input type="text" autocomplete="off">
then the error will not occur, at least according to comments in the bug
report.

Foteos Macrides

unread,
Nov 14, 2004, 12:50:36 PM11/14/04
to

"Martin Honnen" <maho...@yahoo.de> wrote in message
news:cn7s8d$j1...@ripley.netscape.com...

Thank you so much for tracking that down, Martin.

Adding autocomplete="off" to the form start tag or to the individual text
input tags gets rid of the Firefox "internal error" messages in all of my
relevant documents that I tied. I presume that indeed no "internal error" any
longer occurs which might bite Firefox users.

I'm surprised Firefox supports that by default because Firefox is being
promoted as highly secure compared to IE, and under some circumstances
autocomplete can be a security issue like the setting of status bar text by
scripts, which it does block by default.

Fote
--


Justin Wood (Callek)

unread,
Nov 15, 2004, 1:16:04 AM11/15/04
to
Foteos Macrides wrote:
> I normally set the status bar for mouseovers of the labeling anchors, which
> are not actual links such that their href "(javascript:void(0):") is better
> replaced in the status bar by informational strings. Because Firefox is
> distributed with the ability to do that blocked by default, I tried checking
> "Allow scripts to change status bar" in Tools | Options | Web Features |
> Advanced, but that makes no apparent difference.
>

Can you please _not_ use href="javascript:void(0);" and similar code in
your pages, it ruins accessability.

What if a user has Javascript disabled, (your page breaks).

What if *I* the *user* want an anchor to open in a new tab...your page
breaks (I cant).

----

What you should do instead is to link to the "real" page, and any
further JS related things do an onclick="return false;" or have the
function you run return false if the action of "new page" is already
handled. return true if not, (as in the UA should continue as if there
was no script attached).

Thank you for doing _this_ accessible issue on your pages which you
design with accessability in mind.

~Justin Wood (Callek on IRC)

Foteos Macrides

unread,
Nov 15, 2004, 11:15:09 AM11/15/04
to

"Justin Wood (Callek)" <116057...@bacon.NoSpamPlease.qcc.mass.edu> wrote
in message news:cn9hja$g2...@ripley.netscape.com...

> Foteos Macrides wrote:
> > I normally set the status bar for mouseovers of the labeling
> > anchors, which are not actual links such that their
> > href "(javascript:void(0):") is better replaced in the status bar
> > by informational strings.
>
> Can you please _not_ use href="javascript:void(0);" and similar
> code in your pages, it ruins accessability.
>
> What if a user has Javascript disabled, (your page breaks).
>
> What if *I* the *user* want an anchor to open in a new tab...
> your page breaks (I cant).
>
> ----
>
> What you should do instead is to link to the "real" page, and any
> further JS related things do an onclick="return false;" or have the
> function you run return false if the action of "new page" is already
> handled. return true if not, (as in the UA should continue as if there
> was no script attached).
>
> Thank you for doing _this_ accessible issue on your pages which
> you design with accessability in mind.
>
> ~Justin Wood (Callek on IRC)

Thank you for the feedback, Justin, but I am confused by your assertions about
pages breaking when any anchors which are not actual links to another resource
use the "throwaway" URL javascript:void(0); as the href attibute's value, and
the user has disabled javascript.

The "throwaway" value is used because an href is required for those anchors to
be accessible for mouse-based events such as onmouseover, and for
keyboard-navigation-based events such as onfocus. If the anchor is a link to
a "real" page, as you put it (though it could be for a resource other than an
HTML/XML document), then a (typically partial) URL for the "real" page is used
as the href attribute's value (and is resolved by the browser to the full URL)
such that a mouse click on the anchor, or an "activation" (e.g., pressing the
ENTER key on PC keyboards) once keyboard-based navigation has granted the
anchor focus, will access the "new" page (resource) irrespective of whether
scripting is enabled or disabled. Similarly, attempts to activate the anchors
with throwaway href attribute values will do nothing -- as intended --
irregardless of whether scripting is enabled or disabled.

Of course, if scripting is disabled, then script-based "enhancements" of a
document intended by its author will not be available, but that was the user's
own choice, and this does not "break" the page in any meaningful sense of that
term.

Please try my:

http://www.macridesweb.com/oltest/ONFOCUS.html

test page, which includes a "real" link to the simpler test page I previously
posted in this thread:

http://www.macridesweb.com/oltest/FocusProblems.html

with versus without scripting enabled for your browsers. Aside from the
script-based "enhancements" not occurring when scripting is disabled, please
let me know if anything happens which validly can be considered "breaking" of
the page (e.g., makes you unable to fill out and submit or reset the form, or
unable to access other documents via the "real" links).

Fote
--


Martin Honnen

unread,
Nov 15, 2004, 12:08:30 PM11/15/04
to

Foteos Macrides wrote:


> Thank you for the feedback, Justin, but I am confused by your assertions about
> pages breaking when any anchors which are not actual links to another resource
> use the "throwaway" URL javascript:void(0); as the href attibute's value, and
> the user has disabled javascript.

The point is that the URL scheme javascript: is not defined and that
therefore user agents which do not support JavaScript do not or might
not know how to handle it so the usual recommendation is not to use
<a href="javascript: void 0"
onclick="functionName();">...</a>
but instead
<a href="#"
onclick="functionName(); return false;">...</a>
or in case the script does anything you can back up by normal HTML
<a href="fallback.html"
onclick="functionName(); return false;">...</a>

Justin Wood (Callek)

unread,
Nov 15, 2004, 12:09:45 PM11/15/04
to

Ok, I see your point, but I also highly disagree with your format.

what you _want_ is to set the href to the id [name] of the form element
it is referring to (as in a click will "quick-jump" to it...such as for
example

a href="#InputForm"
onfocus='document.getElementsById("InputForm").focus;return false;'
onhover='...' onclick="NoAction();"

function NoAction {
return false;
}

etc.

What this does is allows _all_ links to actually link somewhere, if
clicked in same page and JS is off it will be a jump to that form entry,
without clearing the form data (in current UAs) and if JS is turned on,
and no UA modifiers are chosen, it will do nothing on click. then if I
was to ctrl+click the "link" it would open that same page in a new
window, with a jump to that form element it was refferring to.

you should never use JS as the href attribute, believe it or not, it
_does_ break interoperability, and accessability.

~Justin Wood (Callek on moznet IRC)

Justin Wood (Callek)

unread,
Nov 15, 2004, 12:16:57 PM11/15/04
to
To further, from looking at your source I must say, I did not try and
validate your html, though I can tell you your HTML is not optimal, nor
is your javascript/js/DOM/EcmaScript (whatever you want to call it)

You _should_ be using document.getElementById("foo") syntax rather than
document.f.L1.foo stuff

the later is designed for support only by microsoft, we adopted it to
make sure pages do not break when we visit them, as too many people were
doing it this way (before DOM came around).. [[[let me add the
disclaimer I have not followed our code in this area too much, so could
be incorrect]]]

There may be further things for me to say, but not right now.

~Justin Wood

Foteos Macrides

unread,
Nov 15, 2004, 3:54:49 PM11/15/04
to

"Justin Wood (Callek)" <116057...@bacon.NoSpamPlease.qcc.mass.edu> wrote
in message news:cnaoab$k...@ripley.netscape.com...

Thanks for the additional feedback. In "real" documents that import my script
library I use its OLgetRef('id_or_name') for handling NS4&6-7, IE4-6, Opera7,
Safari, Konqueror, etc. using W3C DOM, IE DOM, or NS4 Level0h (or giving up if
none work :-). But in that simple test file I didn't import my script
library and used very simple code that works to show what's intended. As far
as that goes, however, some time ago I noticed that Google uses
document.f.name.focus() via onload for granting focus to its name'd input for
the search terms. So I inferred that it must be very widely supported even if
not W3C standard and haven't worried about using it in for name'd inputs on
occasion, even if I import my script library and could add an id to use its
function. Was that an incorrect inference?

I'll reply to your and Martin's comments about javascript:void(0); when I have
more time and less fatigue.

Fote
--


Martin Honnen

unread,
Nov 16, 2004, 12:26:30 PM11/16/04
to

Foteos Macrides wrote:

> As far
> as that goes, however, some time ago I noticed that Google uses
> document.f.name.focus() via onload for granting focus to its name'd input for
> the search terms. So I inferred that it must be very widely supported even if
> not W3C standard and haven't worried about using it in for name'd inputs on
> occasion, even if I import my script library and could add an id to use its
> function. Was that an incorrect inference?

In my view it is safe to use
document.formName.elementName
as that was introduced by Netscape 3 and other browsers have followed to
implement that.
It is even safer to use
document.forms.formName.elements.elementName
which is longer but is both compatible with old browsers and with the
W3C DOM (the HTML module in that case).
As for document.getElementById that is restricted to IE 5 and later,
Mozilla, Netscape 6/7, and other modern browsers implementing the W3C
DOM but it doesn't work in older browsers like Netscape 4 and even
throws errors there if used without checking
if (document.getElementById)
first.

Foteos Macrides

unread,
Nov 16, 2004, 6:58:26 PM11/16/04
to

"Martin Honnen" <maho...@yahoo.de> wrote in message
news:cndd89$ad...@ripley.netscape.com...

>
> In my view it is safe to use
> document.formName.elementName
> as that was introduced by Netscape 3 and other browsers
> have followed to implement that.
> It is even safer to use
> document.forms.formName.elements.elementName
> which is longer but is both compatible with old browsers
> and with the W3C DOM (the HTML module in that case).

Thank you again, Martin. I tried the somewhat longer but W3C DOM-compliant
syntax. It indeed works with NS4 and with all of the modern browsers that I
tried. So I'm switching to that and feeling good about the standards
compliance :<) :<)

Fote
--


Foteos Macrides

unread,
Nov 17, 2004, 3:15:48 AM11/17/04
to

"Martin Honnen" <maho...@yahoo.de> wrote in message
news:cndd89$ad...@ripley.netscape.com...
> document.forms.formName.elements.elementName

Ugh, oh... What about the case of radio buttons for which elementName is a
collection? Do I have to assign unique id's to those and end up blowing off
the old browsers?

Other than that case, this still is working out for me as a wonderfully
"backward compatible" W3C-standards-compliant syntax for dealing with named
elements in forms.

Fote
--


Martin Honnen

unread,
Nov 17, 2004, 7:35:17 AM11/17/04
to

Foteos Macrides wrote:

> "Martin Honnen" <maho...@yahoo.de> wrote in message
> news:cndd89$ad...@ripley.netscape.com...
>
>> document.forms.formName.elements.elementName
>
>
> Ugh, oh... What about the case of radio buttons for which elementName is a
> collection? Do I have to assign unique id's to those and end up blowing off
> the old browsers?

No, in that case e.g. if you have two or more
<input type="radio" name="elementName">
then
document.forms.formName.elements.elementName
in all browsers I know returns an array/a collection.

Reply all
Reply to author
Forward
0 new messages