65581 - refocussing and selecting the content doesn't work in the onchange/onblur handlers

Status: RESOLVED INACTIVE

(Core :: DOM: Core & HTML, defect, P4)

Description

[Martin Honnen]

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.

Comment 1

[Martin Honnen]

Attachment: test case (enter text in field and leave field, it should be focussed on and its content selected)

Comment 2

[Stephan Niemz]

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

Comment 3

[martin gosling]

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.

Comment 4

[Stephan Niemz]

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.

Comment 5

[Stephan Niemz]

Attachment: test case for crash

Comment 6

[Stephan Niemz]

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

Comment 7

[Johnny Stenback (:jst)]

Event problem, reassigning to joki.

Comment 8

[Jesse Ruderman]

Might be related to bug 53579.

Comment 9

[John Morrison]

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

Comment 10

[joki (gone)]

Setting milestone

Comment 11

[Tobias Weibel]

Attachment: testcase: load this file and view the source (-->crash)

Comment 12

[Neil Fraser]

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

Comment 13

[joki (gone)]

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.

Comment 14

[Prashant Desale]

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.

Comment 15

[clayton]

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

Comment 16

[Marek Z. Jeziorek]

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)

Comment 17

[joki (gone)]

Moving lower priority bugs out of .9.2 milestone.

Comment 18

[Blake Ross]

Missed 0.9.3.

Comment 19

[saari (gone)]

->0.9.5

Comment 20

[Ashley Bischoff (blog at handcoding.com)]

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

Comment 21

[joki (gone)]

Moving to 0.9.6

Comment 22

[joki (gone)]

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

Comment 23

[joki (gone)]

Moving bugs from 0.9.7 for triaging in 0.9.8

Comment 24

[Peter Trudelle]

nsbeta1+ per ADT triage

Comment 25

[joki (gone)]

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.

Comment 26

[Andy Wood]

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.

Comment 27

[Andy Wood]

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

Comment 28

[Torsten Scheck]

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. 

Comment 29

[Torsten Scheck]

Attachment: test case for timing problems involving focus() and load()

Comment 30

[Torsten Scheck]

Attachment: test case for timing problems - data file

Comment 31

[Torsten Scheck]

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 32

[Torsten Scheck]

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

Comment 33

[Torsten Scheck]

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.

Comment 34

[Torsten Scheck]

Attachment: test case for timing problems involving focus() and load() - with onload

Comment 35

[Brian Ryner (not reading)]

taking.

Comment 36

[Asa Dotzler [:asa]]

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

Comment 37

[cherrieyuen]

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. 

Comment 38

[cherrieyuen]

(In reply to comment #37)

Solution found for my problem:
setTimeout(window,'control.disable=false;control.focus();',1) 

Thanks.

Comment 39

[j.j.]

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)