In the onchange handler of an input element you often check the input made and then - in the case of wrong input - focus back on the field and try to select the input with code alike the following <INPUT TYPE="text" ONCHANGE="if (this.value != 'Kibo') { window.status = 'Wrong input!. Please correct'; this.focus(); this.select(); } else window.status = '';" > This doesn't work however with Mozilla, the onchange fires as the window.status change proves, but neither is the field focussed nor the text selected. When you manually with the mouse focus in the field it shortly flickers as if the select call is then executed.

Confirming with build 2001011420 on NT4 and adding 4xp and correctness keywords, since this works for me with 4.x.

not only limited to onchange. onblur and onfocus show same result. Also forms [0].elements[0].focus() does not function at all, whereas forms[0].elements [0].select() doesn't take the focus! This problem can cause NN6 to go into an infinite loop.

Martin Gosling sent me another test case, which I'm going to attach, and wrote the following: ---------------------------------------------------------------------------v Enter any text (except 'me') into the left box and focus the right - an error message comes up but the text in the left box is not selected having OK'd the alert box. Enter text into the left box and click the button (which focusses the left box) - an infinte loop ensues! ---------------------------------------------------------------------------^ I get the error message, but I suppose that that's the way it should work. When clicking the button after entering something in the left box, I first got two alerts popping up, nothing more. On the second try, I only got one altert - I think that's how it should work. On the third try Mozilla crashed. (Talkback TB24837073W). Build 2001011720 on NT4. Adding crash keyword and increasing severity.

Changing summary to add the crash keyword. (Sorry for the spam.)

Event problem, reassigning to joki.

Might be related to bug 53579.

*** Bug 67418 has been marked as a duplicate of this bug. ***

Setting milestone

*** Bug 71299 has been marked as a duplicate of this bug. ***

Okay, so the select is definitely working, as is the focus method in general. But it seems that calling focus from inside the onchange function does not work. This is likely due to the fact that the onchange method is triggered during the onblur event. Either we set the focus after the fact and override the focus change the script is trying to make or the focus/blur recursive event prevention is killing the new focus call. Needs more research yet.

There could be multiple ways people do data validation on forms. Validating data of any input on onChange event is one of the ways, & it gives importance to this bug. This bug can result in crash as well & also input.focus() & input.select() are not working at all [Working wrong way is different] in this situation. Considering all above senario, nominating this bug for nsbeta1. Adding Keywords mozilla0.9.1, nsbeta1.

Votes and dupes and common sense suggest this needs attention. Marking nsbeta1+ and moving milestone to 0.9.1

setting TM to 0.9.2 per PDT triage (however, you can check it in into 0.9.1 by 18/May/01 11:59pm or into 0.9.2 trunk when it opens)

Moving lower priority bugs out of .9.2 milestone.

Missed 0.9.3.

->0.9.5

*** Bug 102493 has been marked as a duplicate of this bug. ***

Moving to 0.9.6

0.9.6 has passed, moving to 0.9.7. Load balancing 0.9.7 list shortly

Moving bugs from 0.9.7 for triaging in 0.9.8

nsbeta1+ per ADT triage

We still have a problem with the select() method working inside the handler but this no longer crashes (though it does assert). Removing crash keyword and setting to a later milestone as this isn't as big a deal without the crash.

Here's an example of the object.focus() failing in NS7 and Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016 http://www.edmeades.ca/test/focustest.html <script language=javascript> function valField(field) { if (isNaN(field.value)) { alert("Numbers only please."); field.select(); field.focus(); return false; } else { return true; } } </script> <input TYPE="text" ONFOCUS="this.select();" name=Qty OnChange="valField(this);"> No crashes, but focus is allowed to continue to subsequent objects. In IE6.0, this works as expected.

Another user and myself have found that this is still an issue. Is there a workaround to provide field-level validation using JavaScript? I am attempting to just trap alpha characters in a numeric field and force the user to go back and fix before continuing. Focus does not return to the field in question correctly in my current version (just installed 1.4 beta).

I use setTimeout("{inputfield}.focus(); {inputfield}.select();", 0); as a workaround. It's a bit irritating when you use Mozilla to do your first Javascript/DOM steps. I chose Mozilla to code as W3C-conform as possible, but with some crucial bugs it's sometimes really hard to tell if it's a Mozilla bug or just your code. As the DOM stuff like focus() is essential for more complex (intranet-)applications, IMHO the severity should be higher than "minor". I believe in Mozilla. With our feedback and many great software geniuses it will succeed.

I added a test case for timing problems I encountered. According to the O'Reilly book "JavaScript: The Definitve Guide, 4th Edition" the code should work without the setTimeout and alert workarounds. To check out the XML loading part of the test case you have to download the HTML and XML file and work locally, as I didn't manage to load the Bugzilla-attachment from inside the HTML file. Mozilla would be a a great platform for business applications, if DOM2 would work reliably. Please tell me, if there is no problem with Mozilla but I made a mistake. And yes, it's your right to tell me, that I should get the source and debug the problem, instead of complaining.

Comment on attachment 123494 [details] test case for timing problems involving focus() and load() Mozilla 1.4a - Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4a) Gecko/20030401

I understand that the load() timing problem, I decribed in the test case, can be solved by: xmldoc.onload = function () { processXML(); } xmldoc.load("timing_data.xml"); So is my normal, procedural approach totally wrong with JavaScript? I'm okay with that, if I can rely on the "fact" that load is a concurrent task which I have to use accordingly.

taking.

I'm unable to reproduce any crashes with the three testcases and Joki said in comment 25 that we no longer crash. Updating summary.

We have a grid with some enabled and disabled cells, in which each grid cell contains an <input> element. We used setTimeout("{inputfield}.focus(); {inputfield}.select();", 0); as suggested to set cell focus as the grid is tabbed through. The problem happens when I am tabbing from a disabled cell. The focus was lost. No problem using Internet Explorer. I added an "alert" before and after the setTimeout call. I got the focus back to the disabled cell that way. That means clicking a different window will get the focus back. I wonder if we can ever tab correctly in Firefox? Or if anyone can help me with a workaround? (In reply to comment #28) > I use > setTimeout("{inputfield}.focus(); {inputfield}.select();", 0); > as a workaround. > > It's a bit irritating when you use Mozilla to do your first Javascript/DOM > steps. I chose Mozilla to code as W3C-conform as possible, but with some > crucial bugs it's sometimes really hard to tell if it's a Mozilla bug or just > your code. > > As the DOM stuff like focus() is essential for more complex > (intranet-)applications, IMHO the severity should be higher than "minor". > > I believe in Mozilla. With our feedback and many great software geniuses it will > succeed.

(In reply to comment #37) Solution found for my problem: setTimeout(window,'control.disable=false;control.focus();',1) Thanks.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a2pre) Gecko/20070107 Minefield/3.0a2pre attachment (id=22655) fails attachment (id=22874) no crash attachment (id=25144) no crash attachment (id=123507) focus() part wfm. Maybe problems are mixed up here. Somebody with more knowledge should clarify this bug. Thank you really. (Mats Palmgren, I hope, it is ok to CC you here)