Open Bug 53579 Opened 24 years ago Updated 1 year ago

calling this.blur() in onfocus handler or this.focus() in an onblur handler do not work

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

People

(Reporter: dlord, Unassigned)

References

(Blocks 1 open bug)

Details

(Keywords: testcase, topembed-, Whiteboard: [eapp][see comment 34 for workaround][wanted2.1?])

Attachments

(8 files)

Test case from comment
893 bytes, text/html
Details
testcase with intermediate output
1.68 KB, text/html
Details
onblur="this.focus(); return false;"
775 bytes, text/html
Details
onblur="this.focus(); return true;"
772 bytes, text/html
Details
onfocus="this.blur(); return false;"
881 bytes, text/html
Details
onfocus="this.blur(); return true;"
878 bytes, text/html
Details
focus_demo-akoskelin.html
1.53 KB, text/html
Details
patch [Checkin: Comment 54]
5.40 KB, patch
john
: review+
roc
: superreview+
Details | Diff | Splinter Review 
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>
Browser, not engine. Reassigning to Event Handling -
Assignee: rogerl → joki
Component: Javascript Engine → Event Handling
QA Contact: pschwartau → janc
dlord@cardiff.com - I can tab between fields successfully using 20001020 Win95. 
Is this bug fixed?

Gerv
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.
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
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.
"element with flashing insertion point != focused element" also shows up in bug 
39999 and bug 58361.
Blocks: focusblink
well, I can definitely reproduce this.  cc saari on this also.

anthonyd
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.
Assignee: joki → saari
Target Milestone: --- → mozilla0.9.1
->future
Target Milestone: mozilla0.9.1 → Future
not mine, passing on to vladimire
QA Contact: janc → vladimire
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"
Summary: alert() sets focus back to field inappropriately → calling this.blur() in onfocus handler or this.focus() in an onblur handler do not work
Whiteboard: [eapp]
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.
Keywords: nsbeta1+
Target Milestone: Future → ---
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.
Keywords: nsbeta1+ → nsbeta1
Target Milestone: --- → mozilla1.0
nsbeta1- per ADT/Embed triage. No real world test case.
Keywords: nsbeta1 → nsbeta1-
Target Milestone: mozilla1.0 → mozilla1.1
Putting on 1.0 incase I have time because of user feedback
Status: NEW → ASSIGNED
Target Milestone: mozilla1.1 → mozilla1.0
Depends on: 124990
Blocks: 65581
*** Bug 132684 has been marked as a duplicate of this bug. ***
*** Bug 137741 has been marked as a duplicate of this bug. ***
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.  
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.

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.

knoxvillejeff: can't you just make your calculated fields disabled/readonly?

http://www.w3.org/TR/html4/interact/forms.html#adef-readonly
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.
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. 

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.
Renominating based on additional feedback which points this to be a big issue...
Keywords: nsbeta1- → nsbeta1
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.

work around:

<input type="text" id="test" onblur="setTimeout('document.getElementById
(\'test\').focus()', 1)">
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.
Keywords: adt1.0.1, mozilla1.0.1, topembed
Keywords: adt1.0.1
*** Bug 109962 has been marked as a duplicate of this bug. ***
Another workaround is to use setTimeout("element.focus()",0);

The focus is actually changed, but the flashing insertion point is not.
*** Bug 159117 has been marked as a duplicate of this bug. ***
Looks like we have missed the train for 1.0.1. Can we retarget this for 1.2?
plus'ed for embedding
Keywords: topembed → topembed+
saari -- is this something you are gonna have a chance to address for 1.2b?
Keywords: nsbeta1 → nsbeta1+
Whiteboard: [eapp] → [eapp] [adt2]
*** Bug 145875 has been marked as a duplicate of this bug. ***
Blocks: 178882
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 ? 
->bryner, lets try to come up with a fix for this. <thinking>
Assignee: saari → bryner
Status: ASSIGNED → NEW
Target Milestone: mozilla1.0 → mozilla1.4beta
*** Bug 193373 has been marked as a duplicate of this bug. ***
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!
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.
*** Bug 200065 has been marked as a duplicate of this bug. ***
OS: Windows 2000 → All
Hardware: PC → All
*** Bug 202893 has been marked as a duplicate of this bug. ***
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.
topembed-
Keywords: topembed+ → topembed-
Whiteboard: [eapp] [adt2] → [eapp]
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.
Attachment #126066 - Flags: superreview?(roc+moz)
Attachment #126066 - Flags: review?(jkeiser)
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
Attachment #126066 - Flags: superreview?(roc+moz) → superreview+
Attachment #126066 - Flags: review?(jkeiser) → review+
fix checked in.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
Brian: I would like to get this on the 1.4 branch. Is that possible?
Please see bug 213122 for a possible regression from this patch...
I suspect that this also caused this mail compose window regression:
http://bugzilla.mozilla.org/show_bug.cgi?id=214408
Reopening, onblur="this.focus();" is still not working as expected.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Status: REOPENED → ASSIGNED
Target Milestone: mozilla1.4beta → mozilla1.6alpha
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.
Keywords: testcase
*** Bug 199316 has been marked as a duplicate of this bug. ***
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.
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.

*** Bug 233510 has been marked as a duplicate of this bug. ***
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>
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)
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?
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.  
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.
Whiteboard: [eapp] → [eapp] see comment 34 for workaround
(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
Blocks: 278506
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?
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.
Blocks: 334784
Assignee: bryner → events
Status: ASSIGNED → NEW
QA Contact: vladimire → ian
Target Milestone: mozilla1.6alpha → ---
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 :)
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>
----------------------------------------

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.
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.

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?
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...


(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.

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!
No longer blocks: 278506
Attachment #126066 - Attachment description: patch → patch [Checkin: Comment 54]
(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 ?
Flags: wanted1.9.0.x?
Priority: P3 → --
Not a regression or security issue, so not for 1.9.0.x.

Would be nice to fix for next release though.
Flags: wanted1.9.0.x? → wanted1.9.0.x-
(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.
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?
Implementing onbeforedeactivate etc. for 1.9.1 may be a better choice. (That's what is missing...)
Hello . . ., is anybody there?  After eight years of discussion, is anything actually being done about this?
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.
Assignee: events → nobody
QA Contact: ian → events
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()
	{
		
	}
Anything happen here?
Whiteboard: [eapp] see comment 34 for workaround → [eapp][see comment 34 for workaround][wanted2.1?]
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>
I agree with Thomas on this one.
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.
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?
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?
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.
(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".
(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?
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.
(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.)
(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.
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.
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.
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.
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
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;
This bug seems to be fixed at least in firefox 61.
Seems comment72 is still true, see
attachment69050 [details] and
attachment69051 [details]
Component: Event Handling → User events and focus handling
Blocks: 1788981
Severity: normal → S3

This bug seems to be back for me. I can not use on focus on input date anymore (I have to click the calendar icon to make the pop-up show) since the last update!

(In reply to seularts from comment #114)

This bug seems to be back for me. I can not use on focus on input date anymore (I have to click the calendar icon to make the pop-up show) since the last update!

This bug is not fixed ("Status: NEW" is slightly confusing for a 23 years old issue ...)
So did anything change recently?

Please file a new bug for the issue you are seeing. There were changes to the datetime picker in Firefox 109 that are more likely to be related to the problem you're seeing rather than this bug which is 23 years old :)

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

Attachment

General

Creator:
Created:
Updated:
Size: