Closed Bug 65581 Opened 24 years ago Closed 3 years ago

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

Categories

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

defect

Tracking

()

RESOLVED INACTIVE

People

(Reporter: martin.honnen, Unassigned)

References

(Depends on 1 open bug)

Details

(Keywords: dom0, testcase)

Attachments

(5 files, 1 obsolete file)

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.
Keywords: 4xp, correctness
OS: other → All
Hardware: PC → All
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.
Severity: normal → critical
Keywords: crash
Attached file test case for crash
Changing summary to add the crash keyword. (Sorry for the spam.)
Summary: focussing on a field (this.focus) and selecting the content (this.select) doesn't work in the onchange handler → refocussing and selecting the content doesn't work in the onchange/onblur handlers and can cause crash
Event problem, reassigning to joki.
Assignee: jst → joki
Might be related to bug 53579.
*** Bug 67418 has been marked as a duplicate of this bug. ***
Setting milestone
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Keywords: testcase
Keywords: dom0
*** 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.
Target Milestone: mozilla0.9.1 → mozilla0.9.2
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
Keywords: nsbeta1nsbeta1+
Target Milestone: mozilla0.9.2 → mozilla0.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)
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Priority: -- → P4
Moving lower priority bugs out of .9.2 milestone.
Target Milestone: mozilla0.9.2 → mozilla0.9.3
Missed 0.9.3.
Target Milestone: mozilla0.9.3 → mozilla0.9.4
->0.9.5
Target Milestone: mozilla0.9.4 → mozilla0.9.5
*** Bug 102493 has been marked as a duplicate of this bug. ***
Moving to 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
0.9.6 has passed, moving to 0.9.7.  Load balancing 0.9.7 list shortly
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Moving bugs from 0.9.7 for triaging in 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Depends on: 124990
nsbeta1+ per ADT triage
Keywords: nsbeta1+
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.
Severity: critical → minor
Keywords: crash
Target Milestone: mozilla0.9.9 → mozilla1.1
Depends on: 53579
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.
Assignee: joki → bryner
Status: ASSIGNED → NEW
I'm unable to reproduce any crashes with the three testcases and Joki said in
comment 25 that we no longer crash. Updating summary.
Summary: refocussing and selecting the content doesn't work in the onchange/onblur handlers and can cause crash → refocussing and selecting the content doesn't work in the onchange/onblur handlers
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.
Assignee: bryner → general
QA Contact: desale → ian
Target Milestone: mozilla1.1alpha → ---
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)
Assignee: general → nobody
QA Contact: ian → general
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → INACTIVE
You need to log in before you can comment on or make changes to this bug.