From Bugzilla Helper: User-Agent: Mozilla/5.0 (Windows; U; Win95; en-US; rv:0.9.9) Gecko/20020311 BuildID: 2002031104 User actions (click, tab key) override the effect of Javascript focus() routine if called for an onBlur event. The route (possibly along with others) were set on the onBlur event for an input field to do some processing and override the default behaviour when user left this field. Normal behaviour for tab key would jump to next form field, normal behaviour for click is the action for the location of the click. A left-click in the page where there are no link would result in just leaving the form field. However, due to the specific of the processing in that form as the author of the page, I want focus to jump to another field and have the cursor there ready for data entry. Reproducible: Always Steps to Reproduce: 1.write a html document with a form and multiple form fields and (at least) 2 buttons. 2.for one form field, add the onBlur event which executes 'document.form_x.field_y.focus();' 3.click in this field. write something. leave the field with tab, or left click outside. field_y should have focus. However what you see is the result of your action of leaving that field (by whatever method you chose). Actual Results: tab key activates the next form field (in the order of their appearance in the HTML source) left click outside the form fields results in no form field having focus. Expected Results: Behaviour of Netscape 4 (not tested with 3.0) for this code. Also Ie 4&5 tested, same as NS4. Javascript routine has been set there with the exact purpose of overriding the default behaviour of the browser when user leaves that field. However, Mozilla sticks to normal behaviour. From what I see, I think javascript is executed first, then normal UI behaviour is executed, even code that counters the actions of the javascript. I could observe this by setting the objecto to receive focus (via javascript) to be a button and the next field (after the one with onBlur event) also a button. enter the field, leave it with tab key. both buttons have a dotted rectangle drawn on them as if being active buttons. However, the actually active button is the one next to my onBlur field, not the one I wanted active with the javascript. Here's some code example : ------------------------------------------------- [... head section...] <script language="JavaScript"> <!-- // this is generated by dreamweaver 4 function MM_findObj(n, d) { //v4.0 var p,i,x; if(!d) d=document; if((p=n.indexOf("?"))>0&&parent.frames.length) { d=parent.frames[n.substring(p+1)].document; n=n.substring(0,p);} if(!(x=d[n])&&d.all) x=d.all[n]; for (i=0;!x&&i<d.forms.length;i++) x=d.forms[i][n]; for(i=0;!x&&d.layers&&i<d.layers.length;i++) x=MM_findObj(n,d.layers[i].document); if(!x && document.getElementById) x=document.getElementById(n); return x; } function MM_focus(objName) { var obj = MM_findObj(objName); if (obj) obj.focus(); } // the reason for this function is that I have some field names like "a.b" and document.form1.a.b.focus() is nonsense. //--> </script> <form name="form1" method="post" action="/cgi/somecgi"> <input type="text" name"field.y"> <input type="button" name="aproove" value=" Aprobat " > &nbsp;&nbsp;&nbsp; <textarea name="textfield1" cols="55" rows="18" wrap="VIRTUAL" onBlur="MM_focus('field.y');" ></textarea> <input type="submit" name="Submit" value=" Submit "> --------------------------------------------------------------- enter "textfield1". write some text. press tab. "field.y" should have focus (and cursor in it) but in Mozilla the button "Submit" has focus. Now edit the page and change to MM_focus('aproove'); Reload page, enter "textfield1", write something, press tab (or click outside it). Button "submit" has focus, but both buttons ("aproove" and "submit") have a dotted rectangle on them indicating an active button. Expected behaviour is for "field.y" to have focus and in the second case, button "aproove" to have focus. MM_focus is handwritten as a workaround. CGI I'm using requires some field names to be "name1.othername2". The explained behaviour has nothing to do with this. (button named "aproove" contains no dots in it's name and the same happens).

Probably a dup of bug 53579.

Reassigning to Event Handling - this is not a JavaScript Engine issue

This does look exactly like the issue in bug 53579; resolving as duplicate. Andrei, thank you for this report; you will be cc'ed on the other bug - *** This bug has been marked as a duplicate of 53579 ***