Open Bug 53579 Opened 24 years ago Updated 2 years 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
(deleted), text/html
Details
testcase with intermediate output
(deleted), text/html
Details
onblur="this.focus(); return false;"
(deleted), text/html
Details
onblur="this.focus(); return true;"
(deleted), text/html
Details
onfocus="this.blur(); return false;"
(deleted), text/html
Details
onfocus="this.blur(); return true;"
(deleted), text/html
Details
focus_demo-akoskelin.html
(deleted), text/html
Details
patch [Checkin: Comment 54]
(deleted), 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.
Attached file Test case from comment (deleted) —
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.
Attached file testcase with intermediate output (deleted) —
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. ***
Attached file focus_demo-akoskelin.html (deleted) —
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]
Attached patch patch [Checkin: Comment 54] (deleted) — — Splinter Review
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: