Last Comment Bug 53579 - calling this.blur() in onfocus handler or this.focus() in an onblur handler do not work
: calling this.blur() in onfocus handler or this.focus() in an onblur handler d...
Status: NEW
[eapp][see comment 34 for workaround]...
: testcase, topembed-
Product: Core
Classification: Components
Component: Event Handling (show other bugs)
: Trunk
: All All
: -- normal with 48 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
Mentors:
: 109962 132684 137741 145875 159117 193373 199316 200065 202893 203054 233510 278506 293537 439481 746119 799080 (view as bug list)
Depends on: 124990
Blocks: focusblink 65581 125136 178882 334784
  Show dependency treegraph
 
Reported: 2000-09-21 11:16 PDT by Dave Lord
Modified: 2013-12-02 03:05 PST (History)
70 users (show)
jonas: wanted1.9.0.x-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
Test case from comment (893 bytes, text/html)
2000-10-23 09:32 PDT, Gervase Markham [:gerv]
no flags Details
testcase with intermediate output (1.68 KB, text/html)
2000-11-05 23:44 PST, Jesse Ruderman
no flags Details
onblur="this.focus(); return false;" (775 bytes, text/html)
2002-02-12 09:17 PST, Bob Clary [:bc:]
no flags Details
onblur="this.focus(); return true;" (772 bytes, text/html)
2002-02-12 09:18 PST, Bob Clary [:bc:]
no flags Details
onfocus="this.blur(); return false;" (881 bytes, text/html)
2002-02-12 09:19 PST, Bob Clary [:bc:]
no flags Details
onfocus="this.blur(); return true;" (878 bytes, text/html)
2002-02-12 09:20 PST, Bob Clary [:bc:]
no flags Details
focus_demo-akoskelin.html (1.53 KB, text/html)
2003-04-22 13:30 PDT, Al Koskelin
no flags Details
patch [Checkin: Comment 54] (5.40 KB, patch)
2003-06-19 15:47 PDT, Brian Ryner (not reading)
john: review+
roc: superreview+
Details | Diff | Splinter Review

Description Dave Lord 2000-09-21 11:16:44 PDT
From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.01; Windows NT 5.0)
BuildID:    20000080712

Trying to do field validation in forms, alert() sets focus back to field even 
though that field has been blur()'ed and a new field focus()'ed AFTER alert 
runs. Also happens with confirm(). Being called from onfocus(). This works in 
Netscape 4.7 and IE. See attached HTML.

Note that if you move fields with mouse, keyboard focus is different control 
than flashing cursor is in.

Reproducible: Always
Steps to Reproduce:
1.Run attached HTML
2.
3.

Actual Results:  See above							

Expected Results:  alert() should leave focus where I set it.			
				

<html>
  <head>
    <title>
HTML Field Template Demo
    </title>
    <script language="Javascript">
var fBlur = null;
function handleFocus(theField){
	if (fBlur != null && fBlur != theField){
		theField.blur();
		alert( "Bad input. field=" + fBlur.name );
		fBlur.focus();
		return;
	}
	fBlur=theField;
}

    </script>
  </head>
  <body>
    <p> You should not be able to leave a field </p>
    <form name="IATeleform" onsubmit="return checkAll(this)">
      <input type="text" name="b12c96nfConstr_1" id="Constr_1" 
onfocus="handleFocus(this)" maxlength="13" />
      <input type="text" name="b12c96nfConstr_2" id="Constr_2" 
onfocus="handleFocus(this)" maxlength="13" />
      <input type="text" name="b12c96nfConstr_2" id="Constr_3" 
onfocus="handleFocus(this)" maxlength="13" />


    </form>
  </body>
</html>
Comment 1 Phil Schwartau 2000-09-25 20:23:22 PDT
Browser, not engine. Reassigning to Event Handling -
Comment 2 Gervase Markham [:gerv] 2000-10-20 16:38:34 PDT
dlord@cardiff.com - I can tab between fields successfully using 20001020 Win95. 
Is this bug fixed?

Gerv
Comment 3 Dave Lord 2000-10-23 09:15:03 PDT
If you can tab between fields, then the bug is NOT fixed. The HTML I provide is 
supposed to display an error message then position back to the field you were 
just in. I can't even run the current nightly build on Windows 2000 so I can't 
verify that the bug still happens.
Comment 4 Gervase Markham [:gerv] 2000-10-23 09:32:08 PDT
Created attachment 17775 [details]
Test case from comment
Comment 5 Gervase Markham [:gerv] 2000-10-23 09:34:40 PDT
The HTML says "You should not be able to leave a field." I interpreted that as 
the error, rather than the expected behaviour.

Please could you describe exactly what should happen when you load the testcase 
:-)

Gerv
Comment 6 Dave Lord 2000-10-23 09:46:32 PDT
This is a simplification of code used after validating the user's input and 
seeing that it is incorrect. What it should do is this:

When leaving a field:
1) Display an error message that says "Bad input. field=<name of field>"
2) It should then place the focus back in the field so the user can re-enter 
the data.

The problem is that after I place the focus where I want it, Mozilla kindly 
moves it back to where it was before the alert was displayed even though I 
called "blur()" before displaying the alert. This shouldn't happen, and doesn't 
in NS4.7 and IE.
Comment 7 Jesse Ruderman 2000-11-05 23:44:36 PST
Created attachment 18783 [details]
testcase with intermediate output
Comment 8 Jesse Ruderman 2000-11-05 23:48:43 PST
The oddities i see are:

- Tabbing from A to B: although javascript moves focus back to A, and 
everything seems gets the right onfocus events at the right time, B ends up 
with focus.
- Clicking from A to B: focus gets put back in A, but B keeps the flashing 
insertion point.

It doens't seem to matter whether there's an alert right before setting focus, 
or whether there's a .blur() statement.
Comment 9 Jesse Ruderman 2000-12-08 05:01:21 PST
"element with flashing insertion point != focused element" also shows up in bug 
39999 and bug 58361.
Comment 10 anthonyd 2001-01-17 13:24:36 PST
well, I can definitely reproduce this.  cc saari on this also.

anthonyd
Comment 11 joki (gone) 2001-01-23 14:44:22 PST
I talked to saari about this one.  We're not sure what the right solution is so
we'll keep this open and look at it more.
Comment 12 Peter Trudelle 2001-02-28 18:01:21 PST
->future
Comment 13 Jan Carpenter 2001-05-03 17:16:06 PDT
not mine, passing on to vladimire
Comment 14 Bob Clary [:bc:] 2002-02-12 09:14:11 PST
The summary of this bug is misleading. This has nothing to do with the alert
being called in the event handler. The issue is that calling this.blur() in an
onfocus handler or calling this.focus() in an onblur handler do not work. 

This has implications for field by field validation of a form since a web
developer can not a) trap the focus in a particular field and b) can not keep
the focus out of a particular field.

saari, will reconsider the target of future? I consider this important to fix
for web application developers.

I think this bug is related to bug 105129. Bug 105129 deals with calling
input.focus() on a different input than where the onfocus event has fired. Are
they dupes?

changing summary from 
"alert() sets focus back to field inappropriately" 
to 
"calling this.blur() in onfocus handler or this.focus() in an onblur handler do
not work"
Comment 15 Bob Clary [:bc:] 2002-02-12 09:17:02 PST
Created attachment 69050 [details]
onblur="this.focus(); return false;"
Comment 16 Bob Clary [:bc:] 2002-02-12 09:18:35 PST
Created attachment 69051 [details]
onblur="this.focus(); return true;"
Comment 17 Bob Clary [:bc:] 2002-02-12 09:19:47 PST
Created attachment 69052 [details]
onfocus="this.blur(); return false;"
Comment 18 Bob Clary [:bc:] 2002-02-12 09:20:49 PST
Created attachment 69053 [details]
onfocus="this.blur(); return true;"
Comment 19 Heikki Toivonen (remove -bugzilla when emailing directly) 2002-02-12 16:53:12 PST
Major corporations depend on eapp bugs, and need them to be fixed before they
can recommend Mozilla-based products to their customers. Adding nsbeta1+ keyword
and making sure the bugs get re-evaluated if they are targeted beyond 1.0.
Comment 20 Bob Clary [:bc:] 2002-02-13 15:54:08 PST
eapp was incorrectly used to change this to nsbeta1+. Resetting to nsbeta1 to
nominate. This is an important issue and deserves to be nsbeta1+ by the ADT.
Comment 21 Jaime Rodriguez, Jr. 2002-03-04 13:03:43 PST
nsbeta1- per ADT/Embed triage. No real world test case.
Comment 22 saari (gone) 2002-03-07 22:57:19 PST
Putting on 1.0 incase I have time because of user feedback
Comment 23 Boris Zbarsky [:bz] 2002-03-21 18:47:03 PST
*** Bug 132684 has been marked as a duplicate of this bug. ***
Comment 24 Phil Schwartau 2002-04-16 10:28:36 PDT
*** Bug 137741 has been marked as a duplicate of this bug. ***
Comment 25 Alex Vincent [:WeirdAl] 2002-05-15 18:44:24 PDT
This is really, really bad!  Tons and tons of JavaScript developers rely on 
<input type='text' onfocus='this.blur()' />, for browsers that do not support 
the disabled attribute (as in Netscape 4.x).  

I strongly recommend reconsideration of the nsbeta1 keyword.  
Comment 26 Andrei Boros 2002-05-23 23:59:17 PDT
In Mozilla 1.0RC2 :

Behaviour of focus() when called from onBlur event works correctly when onBlur 
was triggered by a mouse event.

If it was triggered by TAB key, it performs the focus(), then performs the 
action that lead to the same result as if only the TAB key was pressed.

Example:

field1
field2
field3 onBlur(field1.focus())
button1

Mouse click outside field3 jumps to field1, then takes the cursor out of it. 
Same behaviour as in NS4.75 
TAB key pressed: cursor jumps to field1, then button1 becomes active.
NS4.75 behaviour is: cursor jumps to field1.

So far this seems to be partially fixed.

Weather the mouse click should leave field1 after jumping the cursor to it might 
be considered debateable, but since currently it behaves the same as NS4.75 
(which is fine with me), other opinions should be taken into account too.
Comment 27 knoxvillejeff 2002-05-24 10:56:13 PDT
I'll have to disagree with Mr. Boros if I understand his code correctly. I'm 
using RC2/Windows and the field will not fire the focus() method in the onblur 
event; mouse-clicking or tabbing make no difference.

I'll prevent my company's users from accessing our site with Mozilla until this 
(huge) bug is fixed; some of our calculated fields use onfocus to prevent 
modification.
Comment 28 Heikki Toivonen (remove -bugzilla when emailing directly) 2002-05-24 11:04:34 PDT
knoxvillejeff: can't you just make your calculated fields disabled/readonly?

http://www.w3.org/TR/html4/interact/forms.html#adef-readonly
Comment 29 knoxvillejeff 2002-05-24 18:58:16 PDT
Heikki,

True enough for newer browsers. However, our company's supported browser is 
Netscape 4.7x (hopefully this will change soon). We're currently rewriting a 
huge app (ripping out layer tags as we go), and writing it so it will work 
cross-platform. As you may know, 4.7x does not support the 'readonly' 
attribute.

On reconsideration, I think what we'll end up doing is including the blur() 
stuff for our old Netscape and readonly for IE, Mozilla, etc. Netscape 4.7x 
will ignore the readonly attribute (and Mozilla ignores the blur() method :)).

Where I see Mozilla creating problems is that existing code on the net using 
the onfocus/onblur technique to prevent users from changing field values will 
break - users will end up changing fields they weren't allowed to.

I really like Mozilla and wish the dev team much success in battling the IE 
monster. A browser based on standards (like Mozilla) will be the ultimate 
winner.
Comment 30 Andrei Boros 2002-05-26 23:58:13 PDT
In reply to comment #28:

In my case, for which I reported the bug in the first place, the functionality 
required is NOT to prevent access/modification of certain fields, but to guide 
the user through the fields of an input form.

User enters text in a TEXTAREA, and upon leaving this field, Javascript 
processes the text and fills out other fields.
The purpose (in my case) of the onBlur(x.focus()) trick is to set focus to 
another input field of this form, thus showing the user another part of the 
page. 
There, the user should be able to check that the script correctly filled out the 
other fields, and enter a value in the field that received focus, then submit 
the form.

Due to the nature of the data that has to be inputed, this solution has been 
found to be the optimum for those who use it.

Considering this, not only fields that user should not be able to modify are an 
issue for this bug. 
Comment 31 Dave Lord 2002-05-28 09:39:22 PDT
We write software that's used by hundreds of companies and government agencies 
to create electronic forms (HTML, PDF, XFORM). This is the number one bug that 
prevents our HTML forms from working well with Mozilla and Netscape. With every 
other browser we can use script in onblur() to validate the value that a user 
entered in a field. We can display an error message and put the cursor back in 
the field that needs to be corrected. With Mozilla we can't do this. I first 
reported this bug nearly two years ago and now I don't even bother testing with 
Mozilla anymore because this issue is still outstanding.
Comment 32 Heikki Toivonen (remove -bugzilla when emailing directly) 2002-05-28 10:05:06 PDT
Renominating based on additional feedback which points this to be a big issue...
Comment 33 knoxvillejeff 2002-05-28 18:18:18 PDT
Given the apparent import of this bug, is it appropriate to bump up the 
priority and/or severity? Would it make any difference?

Also, I'm entering these comments by clicking the Commit button; if this is 
not the correct way or if there's another way, please enlighten me.
Comment 34 Michaël Hompus 2002-06-25 02:08:22 PDT
work around:

<input type="text" id="test" onblur="setTimeout('document.getElementById
(\'test\').focus()', 1)">
Comment 35 David Mischel 2002-06-28 15:13:25 PDT
We too are trying to get rid of Netscape 4.7x and go to Mozilla. This bug has
been a serious problem for us. We use the focus() method to return the user to a
field which requires correction. Our scenario allows the user to keep his/her
hands on the keyboard after an entry error. Field validation checkers return the
focus to the field that needs correct and select the contents. The user, having
dismissed the error popup which came from the error checking routine, need only
type the correct entry and tab again. For this to work, focus had to be returned
to the selected entry.

Many thanks to Michaël Hompus for the suggested work around. We will use that
for the moment pending a true fix. We are hoping it will get into 1.1.
Comment 36 Boris Zbarsky [:bz] 2002-07-17 23:56:14 PDT
*** Bug 109962 has been marked as a duplicate of this bug. ***
Comment 37 Eli Friedman 2002-07-19 22:03:13 PDT
Another workaround is to use setTimeout("element.focus()",0);

The focus is actually changed, but the flashing insertion point is not.
Comment 38 Boris Zbarsky [:bz] 2002-07-24 15:45:09 PDT
*** Bug 159117 has been marked as a duplicate of this bug. ***
Comment 39 Bob Clary [:bc:] 2002-08-16 08:02:14 PDT
Looks like we have missed the train for 1.0.1. Can we retarget this for 1.2?
Comment 40 Michael Dunn 2002-08-20 07:57:54 PDT
plus'ed for embedding
Comment 41 Jaime Rodriguez, Jr. 2002-09-23 09:19:24 PDT
saari -- is this something you are gonna have a chance to address for 1.2b?
Comment 42 Daniel Wang 2002-09-26 00:04:31 PDT
*** Bug 145875 has been marked as a duplicate of this bug. ***
Comment 43 bchiara 2003-01-04 14:20:00 PST
This bug is really hurting, because there is no workaround. I hope it will be
changed to higher priority. Any chance to resolve for 1.3 ? 
Comment 44 saari (gone) 2003-01-06 16:22:34 PST
->bryner, lets try to come up with a fix for this. <thinking>
Comment 45 Boris Zbarsky [:bz] 2003-02-14 21:27:06 PST
*** Bug 193373 has been marked as a duplicate of this bug. ***
Comment 46 kdame 2003-02-24 14:37:36 PST
Is there an expected timeframe in which this will be fixed???  

We're on the verge of changing our requirements to specify that our users only 
use IE - which I'd rather not do.

Thanks!
Comment 47 Derek Anderson 2003-03-12 10:26:15 PST
could this not have been intended?  i can envision this.focus() being filtered
from onblur events for security reasons, lest authors not let their users go
from a field.

a minor security issue, granted.
Comment 48 Boris Zbarsky [:bz] 2003-03-31 22:00:49 PST
*** Bug 200065 has been marked as a duplicate of this bug. ***
Comment 49 José Jeria 2003-04-22 09:17:08 PDT
*** Bug 202893 has been marked as a duplicate of this bug. ***
Comment 50 Al Koskelin 2003-04-22 13:30:33 PDT
Created attachment 121313 [details]
focus_demo-akoskelin.html

This HTML file shows some strange behaviors closely related to everything
mentioned above. I have attached it simply for reference. Included in the file
itself are instructions on how to reproduce the strange behaviors. The
behaviors relate to focus not "completely" changing as it should.
Comment 51 saari (gone) 2003-05-05 13:28:15 PDT
topembed-
Comment 52 Brian Ryner (not reading) 2003-06-19 15:47:38 PDT
Created attachment 126066 [details] [diff] [review]
patch
[Checkin: Comment 54]

This fixes a few issues contributing to this bug:

- Abort firing blurs on the document and/or window if one of the blur handlers
focuses something else.  This ensures that the caret doesn't get confused about
whether it should be active (since it turns off on blur).

- Release any mouse or key grab when the view manager sees a deactivate event. 
This fixes targeting of events if a mousedown handler opens a modal dialog (so
the mouseup is lost).

- Make sure the editor's element is actually focused before enabling the caret.
 It can receive a focus event and no longer be focused, since an onfocus
handler focusing something else may not cancel propagation of the event.
Comment 53 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2003-06-20 05:39:27 PDT
Comment on attachment 126066 [details] [diff] [review]
patch
[Checkin: Comment 54]

The code looks fine, although jkeiser will have to vouch for the event handling
logic
Comment 54 Brian Ryner (not reading) 2003-07-01 17:10:10 PDT
fix checked in.
Comment 55 Bob Clary [:bc:] 2003-07-01 17:23:59 PDT
Brian: I would like to get this on the 1.4 branch. Is that possible?
Comment 56 Mats Palmgren (vacation) 2003-07-22 10:43:44 PDT
Please see bug 213122 for a possible regression from this patch...
Comment 57 David :Bienvenu 2003-08-19 19:32:29 PDT
I suspect that this also caused this mail compose window regression:
http://bugzilla.mozilla.org/show_bug.cgi?id=214408
Comment 58 Brian Ryner (not reading) 2003-09-01 15:17:32 PDT
Reopening, onblur="this.focus();" is still not working as expected.
Comment 59 Sjaak van Schie 2003-09-11 01:03:38 PDT
Seems to be a very difficult issue.
This only is about to celebrate its 3th birthday.

This is also very critical for us.
Because of this field validation is not possible.

We like to recomment Netscape versions higher than 4.7 to our customers.
However this bugs hinders us from doing that.
Comment 60 louis bennett 2003-10-13 12:33:25 PDT
*** Bug 199316 has been marked as a duplicate of this bug. ***
Comment 61 Karri Parola 2003-10-29 07:27:23 PST
Disabling the input element works, but the contents of the element are difficult
to read in Mozilla when disabled.  I want to use
onfocus:javascript:"this.blur(); return false;" to create easy to read , read
only input elements.
Comment 62 Brian Ryner (not reading) 2003-11-09 22:35:41 PST
The remaining problem that I noted (onblur=this.focus()) is probably caused by
us not detecting that the blur handler did something.

In the patch that was checked in for this bug, we look at whether the focus
changed during execution of the blur handler.  If it did, we abort the normal
focus change.  In this case, the blur handler did not change the focus - the
element is still "focused" as the blur handler fires.  However, I think we
should note the fact that the blur handler re-focused the element and also abort
the normal focus change in this case.
Comment 63 Mats Palmgren (vacation) 2004-02-09 10:04:54 PST
*** Bug 233510 has been marked as a duplicate of this bug. ***
Comment 64 Jan Drda 2004-02-25 11:59:37 PST
I spent a couple of hours developing some solution, that can bypass this bug 
(the same bug is in my NN 7.1, IE and Opera works fine). Especially I wanted 
check some fields and do not let user leave the field until the value is 
correct. The most simple and user-friendly way is following.
Tested on IE 6SP1, Opera 7.23, Mozilla Firefox 0.8, Mozilla Firebird 0.7, 
Netscape Navigator 7.1


<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 
4.01//EN" "http://www.w3.org/TR/html4/strict.dtd">
<html lang="en">
<head>
<title>Bug bypass</title>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
<script type="text/javascript">
<!--
// Check if number is in interval otherwise show input dialog to correct value
function checkNumber(field) {
  if(field.value < 0 || field.value > 10){
    userInput = window.prompt('Value must be between 0 - 10. Correct the 
value:', field.value);
    
    // User cannot use CANCEL button (CANCEL returns null)
    if(userInput != null){
      field.value = userInput;
    }

    // Check value again
    checkNumber(field);
  }
}
-->
</script>
</head>
<body>
<form action="./process.php">
  <div>
    <label for="userNumber1">User number 1:</label>
    <input type="text" id="userNumber1" onblur="checkNumber(this)">
	<br>
	<label for="userNumber2">User number 2:</label>
    <input type="text" id="userNumber2" onblur="checkNumber(this)">
  </div>
</form>
</body>
</html>
Comment 65 Brian Ewins 2004-03-18 04:52:31 PST
I've not seen anyone mention that this bug causes a hang. The O'Reilly
OnJava.com reader survey:
http://www.zoomerang.com/recipient/survey.zgi?p=WEB2E2KF8BU

...(godawful html, isn't it) is replete with faked-up checkbox/radio controls
using markup like:
<a href="#" onfocus="this.blur()" onclick="fprvSwitch_choice_1(
'choice_1_4',4);return false;"><img border="0" name="choice_1_4" ...

In this example, pressing tab twice on the page hangs mozilla 1.6. I can
reproduce this with the page cut down to just the onfocus/blur:

<html>
<head>
<title>Hammertime</title>
</head>
<body>
<a href="#" onfocus="this.blur()">Can't touch this</a>
</body>
</html>

(open and press tab a couple of times)
Comment 66 giordano 2004-11-19 00:11:14 PST
It is nearly end of 2004 and this bug persist for 4 years.
I tried the attachment onblur="this.focus(); return false;" in FireFox 1.0PR
and it still does not work well.
I have a field validation code and want to return the focus to the field after
an alert if the validation fails. It works in IE.
I tried the setTimeout workaround. It works when moving to the next text field,
but I can't prevent user to click the submit button.
Is this a feature. Should I stop trying to validate input?
Comment 67 Ian 2004-11-22 12:45:38 PST
The side effects of this bug are brutal when it comes to
trying to use Mozilla for any serious business forms which
often rely on onBlur to stop the user from entering bogus data. 
This really needs some more attention. Setting focus from an 
onBlur  event needs to be handled specially.   It basically should 
stop  all pending events in the queue.  The onblur hook appears
to correctly stop all other event processing while it's running, so
there's a window of opportunity here to do the right thing.
Here's what I propose.  Immediately following the
call to the onblur hook, look for a new focus event at the
end of the event queue, and if found, wipe out all the 
events  ahead of it in the queue.   Think about it.
This stops TAB, and click, and any other key or button event
from firing if the focus event takes you elsewhere.    It doesn't
matter if I'm setting focus to the same field, or a different
field, I want to override all "normal behavior", as soon
as that focus event is set.  And if for some reason several
focus events were created inside the onblur hook, I only want 
the last one.    The fact that this works in
every other browser out there, makes me think that it's not
really that hard of a problem.  Certainly not a problem
that can't be fixed in 4 years.  
Comment 68 ms 2004-12-06 01:25:38 PST
can you please increase the priority and severity, because so many customers
want to change to firefox 1.0 at the moment?
many thanks for the workaround comment34. i had a lot of invalid data before.
Comment 69 Patryk Zawadzki 2004-12-08 06:08:22 PST
(In reply to comment #65)
> ...(godawful html, isn't it) is replete with faked-up checkbox/radio controls
> using markup like:
> <a href="#" onfocus="this.blur()" onclick="fprvSwitch_choice_1(
> 'choice_1_4',4);return false;"><img border="0" name="choice_1_4" ...

I second that, this is a well known bug causing the browser to fall into an
infinite recursive loop of focusing and blurring a single element as soon as you
tab into an element that has onfocus="blur()"

Please bump it up for fixing
Comment 70 yatahonga 2005-07-29 06:38:16 PDT
I cannot believe that this major bug is still not fixed after 5 years!

As mentionned many times already, it prevents any kind of serious interactive
form field validation with Firefox. It's breaking my heart to tell all our
corporate customers to avoid Firefox for only one reason: Bug 53579.

Anybody got an update? Anybody working on it? Will it ever be solved?
Comment 71 Anthon Pang 2005-12-19 19:53:19 PST
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.8) Gecko/20051111 Firefox/1.5

I presume this is the sequence of events that we would like to see (assuming bug 243816 is also fixed):

1. A loses focus, B gains focus
2. A's onchange handler is called if value has changed since A received focus
3. A's onblur handler is called
4. B's onfocus handler is called _only_ if B still has focus

BTW we tried the setTimeout workaround from comment 34 (or comment 37), but opted to not use it after we encountered the double alert anomaly described in bug 297134.
Comment 72 j.j. 2007-01-07 18:03:57 PST
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070107 Minefield/3.0a2pre
This is whats going on for me:

wfm:  attachment (id=17775)       // was original bug report
wfm:  attachment (id=18783)
fails (comp. with IE): attachment (id=69050)
fails (comp. with IE): attachment (id=69051)
wfm:  attachment (id=69052)
wfm:  attachment (id=69053)
wfm:  attachment (id=121313)

So it is 71.4% fixed :)
Comment 73 Nils Hammar 2007-01-11 02:20:27 PST
A workaround for the problem is to use a JavaScript timer to get the expected behavior.

Example code below that uses the "setTimeout()" function to get the expected behavior:
----------------------------------------
<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>
<head>
<title>HTML Field Template Demo</title>
<script language="Javascript">
<!--
var reFocusField;

function reFocus()
{
	reFocusField.focus();
}

function checkNumber(field)
{
	if (field.value < 0 || field.value > 10)
	{
		reFocusField=field;
		alert("Not between 0 and 10");
		setTimeout("reFocus()", 100);
		// field.focus();
	}
}
// -->
</script>
</head>
<body>
<form>
	Enter a number between 0 and 10.
	<div>
		<label for="userNumber1">User number 1:</label>
		<input type="text" id="userNumber1" onblur="checkNumber(this)">
	<br>
		<label for="userNumber2">User number 2:</label>
		<input type="text" id="userNumber2" onblur="checkNumber(this)">
	</div>
</form>
</html>
----------------------------------------
Comment 74 Mike Moening 2007-04-04 14:05:36 PDT
The workarounds in #34 and #74 DO NOT work in all cases.
If the TextArea loses focus because the window looses focus the it won't work right.

What does it take to get this bug fixed?
A bug like this should have been fixed 7 years ago!

Application developers need field by field validation.
Without a doubt this is one of the biggest reasons people don't use Firefox.
Comment 75 Nick Lewis 2007-07-12 02:57:17 PDT
According to the DOM team homepage
(http://www.mozilla.org/docs/dom/mozilla/team.html)
the person responsible for Form Controls and Form Submission code is John Keiser
However I see little sign of Mozilla activity from him since he joined Microsoft
Perhaps this devastating bug could be reassigned to a different team or someone else could look at it.
I see that the all encompasing focus bug report 178324 is being addressed by Mats Palmgren (mailto:mats.palmgren@bredband.net) so perhaps this bug will be addressed as part of that work. I will certainly celebrate if it is.
Comment 76 Jan So 2007-11-26 19:22:55 PST
Wow five years. With all the hype that FF was getting, I can't believe that this bug was overlooked for so many years.

If anyone is interested in fixing this bug, how do one begin? standards in fixing it? checking in? Any links on how to contribute a fix?
Comment 77 robinpelgrim 2007-12-01 05:48:34 PST
The real problem here is that the blur/focus method isn't suitable for validating a control-value i.e.:
Control validation means: do not blur when the value is not correct.
(The onblur { focus() } construction is really too stupid for words!)

So what you need is something like: onbeforeblur that is cancelable.

I don't know why I cannot find it in any w3c spec (are they stupid there, or do I mis something?),
it's obvious that there should be a 'onbeforeblur' event to do control validition.

In Internet Explorer there is 'onbeforedeactivate' which is exactly what you need.

It is annoying to see there is no proper way to validate a control in FF.
It is even more annoying there is nothing in the w3c specs about this.

It is my opinion that onbeforedeactivate should be implemented (or call it onBeforeDOMFocusOut, or just implement onDOMFocusOut and make is cancelable).

Since showModalDialog is now supported, the only thing I'am missing now is an 'onbeforedeactivate' event, to port our application to FF :(.

This should have been implemented years ago...

Comment 78 Nils Hammar 2007-12-01 08:57:58 PST
(In reply to comment #77)
> (The onblur { focus() } construction is really too stupid for words!)

It may seem stupid, but some browsers behave differently and causes problems with the alternative 'onchange', in which case onblur is left as a trigger for leaving the field and then a validation of the field in question can occur where it's possible that you want to re-focus the field.

Just because something seems stupid doesn't mean it is stupid. It's just different and may be the ideal solution for the application where it occurs.
Comment 79 robinpelgrim 2007-12-01 10:29:40 PST
No, it's not just different.
It's wrong!

A simple use case to explain this:
When you have an input field with a value that isn't allowed, and than you press the OK button, you just are to late at the onblur event since (w3c) can NOT be canceled, so the events flow will continue: something like:
<onkeydown [OK Button]> <onblur [Input]> <onfocus[OK Button]> <onkeyup[OK Button]> <onclick[OK Button]>
so technically speaking the focus() command should cause a <onblur[OK Button]> <onfocus[input]> event AFTER <onclick> and since you were validating you do not want the onclick to be happen.
Well you just could say: well, just skip the <onkeyup[OK Button]> <onfocus[OK Button]> <onclick[OK Button]> events when doing onfocus() but that is canceling the event (which is not w3c compliant).
In my opinion that would be just a dirty implementation.

Well when implementing preventDefault() on the onblur event (and also specifing to which control the focus is going to) I would be happy.

Well, maybe it's not stupid, but there are way better solutions (by implementing onbeforedeactivate).

The current implementation just does NOT work!

Comment 80 Serge Gautherie (:sgautherie) 2008-05-10 07:32:00 PDT
*** Bug 293537 has been marked as a duplicate of this bug. ***
Comment 81 Serge Gautherie (:sgautherie) 2008-05-10 07:44:39 PDT
*** Bug 278506 has been marked as a duplicate of this bug. ***
Comment 82 Serge Gautherie (:sgautherie) 2008-05-10 08:04:42 PDT
(In reply to comment #81)
> *** Bug 278506 has been marked as a duplicate of this bug. ***

This is a case of |this.focus()|, "fixed" by comment 73.
I understand this is why this bug was reopened in comment 58.

(In reply to comment #80)
> *** Bug 293537 has been marked as a duplicate of this bug. ***

This one uses |document.forms[0].required_email.focus()|, "fixed" by comment 34.
As I (+/-) read this bug, this case "should" have been fixed by comment 54 checkin, should it not ?
Comment 83 Jonas Sicking (:sicking) PTO Until July 5th 2008-05-22 14:52:21 PDT
Not a regression or security issue, so not for 1.9.0.x.

Would be nice to fix for next release though.
Comment 84 Bruce Terry 2008-05-22 20:35:04 PDT
(In reply to comment #82 re duplicate Bug 293537)

I tried fixing <http://bible.ovu.edu/bible/mozitest.htm> with the work around as indicated using the |setTimeout("document.forms[0].required_email.focus()", 0);| command as indicated.  It does cause the form to work as in Opera and IE without the work around.  However, after leaving Firefox 2.0 and returning to it, I could not use any form (either on that form or on my webmail) until I closed the tab that contained the form.

This bug was first reported almost 8 years ago.  It does not occur in Netscape 4.7, IE, or Opera.  It should not require a work around that has side effects.
Comment 85 石庭豐 (Seak, Teng-Fong) 2008-05-26 13:52:13 PDT
I use a modified version of setTimeout: using 50 instead of 0 and I don't seem to have your problem.  Could you try it and confirm if it works for you?
Comment 86 robinpelgrim 2008-05-26 14:32:16 PDT
Implementing onbeforedeactivate etc. for 1.9.1 may be a better choice. (That's what is missing...)
Comment 87 Scot P 2008-06-12 09:10:32 PDT
Hello . . ., is anybody there?  After eight years of discussion, is anything actually being done about this?
Comment 88 Boris Zbarsky [:bz] 2008-06-16 20:01:07 PDT
*** Bug 439481 has been marked as a duplicate of this bug. ***
Comment 89 Michael Ratcliffe [:miker] [:mratcliffe] 2008-06-17 04:26:55 PDT
The setTimeout workaround does not work when refocusing a window.

e.g. window.document.onblur=function() {window.focus();};

There is currently no way to get this to work.

The original ticket was logged on 2000-09-21 so surely it is time for somebody to take a look at this ... especially because Boris Zbarsky says he has no time until May 2009.
Comment 90 Ole Ersoy 2010-01-05 19:21:54 PST
Just wanted to note that this also prevents creating a focus method on dojo components.  For example attempting to run a method defined like this:

	focus: function()
	{
		
	}

on a dojo class instance causes the script to stop running.  

I had to hack around like this:
	//STUB - OVERRIDE TO PROVIDE FOCUS ON THE COMPONENT'S INPUT FIELD
	//https://bugzilla.mozilla.org/show_bug.cgi?id=53579
	//We would just name it focus...but firefox breaks.
	focusComponent: function()
	{
		
	}
Comment 91 gossi 2010-08-25 17:01:10 PDT
Anything happen here?
Comment 92 :Ms2ger (⌚ UTC+1/+2) 2010-12-12 04:26:43 PST
*** Bug 203054 has been marked as a duplicate of this bug. ***
Comment 93 Thomas 'PointedEars' Lahn 2011-01-05 16:22:52 PST
IMHO this rather ancient bug should finally be closed and marked WONTFIX, because accessibility/usability guidelines, and I daresay common sense too, suggest that software developers should not be allowed to trap the user in any way.

If your users want to go on filling out other fields first and leave this one field invalid (perhaps only for the time being), or if they want to focus other windows, let them[1]!

If other browsers do this differently, they have it wrong.  Mozilla should not follow their backwards lead, but take the lead towards a more user-friendly future on the Web.

There are a lot better ways to ensure properly filled-out forms, like using the DOM to show boxes that explain validation errors on blur contextually, or doing form validation on submit (you have to do that anyway on the client to avoid roundtrips, and on the server in case there is no client-side scripting).  And certainly there are better ways to develop a Web application than to trap the user in a certain browser window.

[1] or make your special window truly modal by using privileges and 

  window.open("...", "...", "..., modal");

see <https://developer.mozilla.org/en/DOM/window.open#Features_requiring_privileges>
Comment 94 Michael Ratcliffe [:miker] [:mratcliffe] 2011-01-06 02:36:23 PST
I agree with Thomas on this one.
Comment 95 gossi 2011-01-06 05:08:37 PST
I disagree with Thomas.

focus and blur handler do not only occur on form element. They also occur on elements that have a tabindex="0" attribute. This way you can write your own ui with divs and your own handlers to recreate common ui accessibility/usability behavior. In this case it's absolutely required to be able to modify focus during blur.

I agree with the default behavior.
Comment 96 Mike Moening 2011-01-06 06:55:35 PST
While I understand Thomas's argument, I find it to be a very narrow view of what the web can do.  His argument is valid for simple forms on web pages but the browser has become an OS of sorts for developing full featured web apps and developers need more control over their widgets.  

We have complex spreadsheet-like widgets that follow sophisticated rules that require validation before column traversal.  Because of this bug we can't use firefox to the full extent and a bug like this could eventually cause us to look for other target environments.  Yes, a malicious coder could toggle between two or more input elements infinitely, causing the browser to hang, but the same coder could just as easily type while(true); and be done with it.  The hung script warning should then eventually pop up either way.

I still think this bug deserves fixing.

This bug has 62 CC's and 40 votes at this time.
WONTFIX is not a viable option.

Can Mozilla finally just fix this??
It's sort of embarassing.
No more excuses.

PLEASE?
Comment 97 :Ms2ger (⌚ UTC+1/+2) 2011-01-06 07:52:34 PST
May I remind people of the Bugzilla Etiquette (<https://bugzilla.mozilla.org/page.cgi?id=etiquette.html>), in particular the following:

> 1. No pointless comments. Unless you have something constructive and helpful
>    to say, do not add a comment to a bug. In bugs where there is a heated
>    debate going on, you should be even more inclined not to add a comment.
>    Unless you have something new to contribute, then the bug owner is aware
>    of all the issues, and will make a judgement as to what to do. If you
>    agree the bug should be fixed, vote for it. Additional "I see this too"
>    or "It works for me" comments are unnecessary unless they are on a
>    different platform or a significantly different build. Constructive and
>    helpful thoughts unrelated to the topic of the bug should go in the
>    appropriate newsgroup.
>
> 2. No obligation. "Open Source" is not the same as "the developers must do
>    my bidding." The only person who has any obligation to fix the bugs you
>    want fixed is you. Never act as if you expect someone to fix a bug by a
>    particular date or release. This is merely obnoxious, and is likely to
>    get the bug ignored. 

Please?
Comment 98 Bruce Terry 2011-01-06 20:27:01 PST
I've been working on a work around for this bug and discovered that in firefox I can give focus to any text input field previous or subsequent, but not to the field that has been blurred. It is almost like giving it focus does not remove the blur.  Don't know what kind of coding causes this, but it is a coding mistake.  It needs to be fixed.  Apparently the coding is not checking to see if the return value is false before giving focus to the next field.  In reference to a similar question on the page whose URL Thomas gives, we find: "The purpose of the return false in the code is to cancel default action of the link."  In the same way, return false should cancel a focus to the next field, which is the default action.

To say that validation only needs to be done at the time of submit is very arbitrary.  Such forms I personally find aggravating since one often has to go through the whole form again to correct one mistake.
Comment 99 Thomas 'PointedEars' Lahn 2011-01-07 10:15:31 PST
(In reply to comment #98)
> To say that validation only needs to be done at the time of submit is very
> arbitrary.  Such forms I personally find aggravating since one often has to go
> through the whole form again to correct one mistake.

Bruce, I did not say that.  I mentioned that form validation must also be done on form submit (unless you want to make unnecessary roundtrips to the server and back again).  I also said that there are better, i.e. more user-friendly, more accessibility-complying ways than trapping the user by focus in a control, such as displaying a message next to it or in an error summary (preferably not in an alert(), but an [X]HTML element).

Actually, I think this bug is still open partially because some people have not realized that it was opened for Netscape 4 (R.I.P.)  The NS 4 DOM did not support the W3C DOM or any other equivalent way of modifying a document on the fly (short of rewriting [parts of] it; no, document.layers[…].document.write(…) was never a viable replacement for MSHTML's document.all).  But the Gecko DOM does.  Let's move on to the 21st century and tell our users *what* they are doing wrong instead of simply saying "don't go away".
Comment 100 Michael Ratcliffe [:miker] [:mratcliffe] 2011-01-07 11:20:48 PST
(In reply to comment #96)
> We have complex spreadsheet-like widgets that follow sophisticated rules that
> require validation before column traversal.

Would it not ake more sense to display an error essage in a div to the user then the user clicks ok and you refocus the cell again?
Comment 101 Bruce Terry 2011-01-07 14:08:32 PST
Whether by alert() or div() to inform the user of the error, the problem is that a refocus on the cell fails presumably because the return false is ignored.
Comment 102 Thomas 'PointedEars' Lahn 2011-01-07 21:15:20 PST
(In reply to comment #101)
> Whether by alert() or div() to inform the user of the error, the problem is
> that a refocus on the cell fails presumably because the return false is
> ignored.

True, but my point is that I can see nothing wrong with that, and I am not convinced at all that this is a bug as in "programming mistake".

1. From the Web standards perspective, the `blur' event MUST NOT be cancelable.  See W3C DOM Level 2+ Events.

2. From the usability/accessibility perspective, `blur' is not one of the events that should be cancelable because canceling the `blur' event (or refocusing a control for which the `blur' event just occurred) would mean to trap the user in that control, against their expectations.  Users should be allowed to move on, and perhaps to use that control properly later.  This is also backed by WCAG 2.0 when it says "Guideline 3.3 Input Assistance: Help users avoid and correct mistakes."  Trapping users in a control is effectively hindering, not helping them.  Isn't it a bit presumptuous for a Web application developer to consider their humble application's control to be paramount to all the user's work?

3. Spreadsheet Web applications (comment #96): The user's expectation from the desktop spreadsheet applications I know is that if they press Tab they move on to the next cell in the row, regardless of the value they typed.  They expect that an error value is displayed in the formerly focused cell if the value does not make sense (which corresponds with my suggestion and WCAG's recommendation [3.3.1, Level A] on how to notify them).  They do _not_ expect to be trapped in that cell forever, being prevented from making any other input until they eventuelly get the cell's value right.  So I do not think the spreadsheet argument holds water.

(4. Bugzilla etiquette/Mozilla newsgroups: Thanks Ms2ger for the reminder.  But sorry, AFAICS most of them, like mozilla.dev.apps.firefox, are empty now.  Is anyone even subscribed to them?  If yes, which one would be the appropriate one in this case?  TIA.)
Comment 103 Nils Hammar 2011-01-07 22:06:38 PST
(In reply to comment #102)
> (In reply to comment #101)
> 
> 2. From the usability/accessibility perspective, `blur' is not one of the
> events that should be cancelable because canceling the `blur' event (or
> refocusing a control for which the `blur' event just occurred) would mean to
> trap the user in that control, against their expectations.  Users should be
> allowed to move on, and perhaps to use that control properly later.  This is
> also backed by WCAG 2.0 when it says "Guideline 3.3 Input Assistance: Help
> users avoid and correct mistakes."  Trapping users in a control is effectively
> hindering, not helping them.  Isn't it a bit presumptuous for a Web application
> developer to consider their humble application's control to be paramount to all
> the user's work?

On the contrary - sending back the user to a control will help them correct their mistakes. If you can't programmatically send them back to the right control it's harder to correct the input data.

It is then up to the coder to design the code sending them back so that the user actually has a way of exiting the control without being locked in it. If a field shall only require digits or be empty the user shouldn't be able to exit the field when there is something else entered.

And there are ways to achieve the goal today too, but it requires a more complex coding for the developer. And complex coding means a larger risk for unnecessary bugs. Trigging a timer event is what comes to mind.

And just because the W3C spec says something doesn't make it right. Even they are able to come up short.
Comment 104 Bruce Terry 2011-01-08 17:02:45 PST
The input field that my form page is trapping if incorrect information is entered is an email address.  The form page will not work if an invalid email address is entered.

Just tonight I submitted information on a form which did not validate until submit was pushed.  I wondered why the form did not work until I finally figured out there was an error message hidden down the page that I had to scroll down to see.  Maybe I'm not the brightest user, but that was not user friendly.
Comment 105 Edam 2011-01-09 08:43:38 PST
I think that we should keep the validity of this bug in context.

We are not talking about UI design here (Thomas, in particular). The issue here is whether or not a developer has the *ability* to keep a user's focus at an input field at all, not whether he should use that ability in a given situation, nor whether/how he should additionally inform the user of that action. Developers devise poor UIs notwithstanding this bug!

As someone else has pointed out, HTML is used for more than pages on the world wide web. While this bug remains unfixed, the ability to keep a user's focus at a form element is not available to a developer in any circumstances that HTML might be used. I don't think this is desirable, even if using the ability might be a poor design choice in most situations.
Comment 106 Matthias Versen [:Matti] 2012-04-18 21:45:33 PDT
*** Bug 746119 has been marked as a duplicate of this bug. ***
Comment 107 John Goold 2012-08-29 17:18:57 PDT
Almost identical problem with onchange().

For what it is worth, this can be used without "trapping the user".

Works in Chrome (no time to test other browsers).

I had a more complete comment, but bugzilla crashed (bug report submitted) and as mentioned, I don't have the time to muck around.
Comment 108 Matthias Versen [:Matti] 2012-10-08 09:40:31 PDT
*** Bug 799080 has been marked as a duplicate of this bug. ***
Comment 109 john 2012-10-08 10:55:35 PDT
it is hard to believe that this has not been fixed being the first report some 12 years ago. and for what it is worth mucking around can solve problems
Comment 110 john 2012-10-10 13:40:55 PDT
here is how i got to work
place this in your fault area of your script.
will take you to the invalid input box and you can also 
say invalid or what ever you want in the box


document.myForm.ckroute.value = "";
setTimeout("document.myForm.ckroute.value='invalid'",1000)
setTimeout("document.myForm.ckroute.select()",4);
return false;

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