186405 - Mozilla does not select text in form element (text input) that has focus on page load

Status: RESOLVED WORKSFORME

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

Description

[Jens Müller (:tessarakt)]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.2.1) Gecko/20021130
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-AT; rv:1.2.1) Gecko/20021130

(form handling differs from IE's)

Reproducible: Always

Steps to Reproduce:
1. Load the mentioned page.

-> The focus is on the text input on the top containing the text "840400".
Actual Results:  
The text input has the focus, but its contents are not selected. Instead, the
text cursor is at the end of the text.

Expected Results:  
Mozilla should  select the text in the element having focus so that user can
immediately enter a new number (as IE5 does).

Comment 1

[Vladimir Ermakov]

Attachment: testcase

Testcase demonstrating that .select() method does not do anything, even though
is defined.

Comment 2

[Vladimir Ermakov]

This works on 7.01 on mac, but doesnt work on current trunk 2002-12-20-08-trunk
on win2k
This is no dom events,looks like dom level 0

Comment 3

[Viktor Radnai]

The same thing happens to textareas.

I have verified this bug on build 2003010205 on Win2k.
Works correctly on Mozilla 1.1 on Win2k.

Comment 4

[Viktor Radnai]

The same thing happens to textareas.

I have verified this bug on build 2003010205 on Win2k.
Works correctly on Mozilla 1.1 on Win2k.

Comment 5

[Sebastian Lisken]

Attachment: slightly extended testcase

I use an extended version of the attached form as my start page
(it's on "http://www.mathematik.uni-bielefeld.de/~lisken/start.html").
If you look at the JS code, you see that I try to make text inputs
behave more like they do under Windows - tabbing into a new input
should select the new input's contents. This works and has done since
Netscape 3. It still does, apart from the bug - the input I try to
select and focus at load time, using JavaScript, isn't selected. If
you click the link and then use the "back" button, again the field
isn't selected. This worked in Mozilla 1.1, and stopped working in
1.2 (I don't know if 1.2 or 1.2.1).

Comment 6

[Johnny Stenback (:jst)]

Mass-reassigning bugs to [e-mail]

Comment 7

[Sebastian Lisken]

Any developments on this one? It certainly is the single most disturbing
navigator feature for me. It might even make me go back to 1.1 (the last
version not showing the bug) - not that I assume anyone would be more
bothered by that than by the fact that there is something wrong in the DOM
here. :-)

Comment 8

[Wayne Schroeder]

I have also experienced this.  I am coding a new 'module' for a web application
where I work and just noticed that my .select and .focus weren't working exactly
right.  If you step through the code right over the .select it works fine.. but
running full speed outside the js debugger it does not select.  This stuff used
to work great.  

Mozilla 1.3

Comment 9

[Heikki Toivonen (remove -bugzilla when emailing directly)]

We should get some traction on this.

Comment 10

[Samir Gehani]

adt: nsbeta1-

Comment 11

[Sebastian Lisken]

In my previously mentioned start page,
"http://www.mathematik.uni-bielefeld.de/~lisken/start.html",
I have now implemented a workaround - after almost giving up
hope that anyone is going to look into this bug, which I find
disappointing. The select() won't work in code that is included
in the HTML code (i.e. the code running on page load), but it
does work when put into a "setTimeout( <code invoking select> , 1)".
This is not nice (in fact it introduces some slight and unwanted
behavioural change in my start page), but it is a workaround
for this issue.

Comment 12

[Stefan Borggraefe]

Both attached test cases work for me with a current nightly build on Windows XP.
Can someone still reproduce this?

Comment 13

[Sebastian Lisken]

I confirm the bug has gone (not completely, see below) with
the latest Nightly as well as the release version of 1.5,
under Windows 2000. Wow! Not completely because when you open
the test cases in a new tab (right click, "Open Link in New Tab")
the erroneous behaviour persists (at least in 1.5). My start
page (as mentioned previously) behaves in the same way (if I
take out the workaround I last reported). Interesting change.

Comment 14

[Stefan Borggraefe]

Sebastian: Only the first testcase still shows the bug when loading it in a new
tab. Even this does work on Linux. But not on Windows. When the alert() is
removed from the first testcase, it works on Windows too. So this is probably a
focus-issue associated with alerts.

Perhaps it is the best to resolve this bug as WORKSFORME and file a new one
about the remaining issue.

Comment 15

[Sebastian Lisken]

Testing with the latest Nightly under Windows 2000, both testcases
work (don't show this bug) even when opened in a new tab. I'll
probably skip 1.5 and jump just to 1.6a.

Comment 16

[Stefan Borggraefe]

Marking WFM.

Comment 17

[Sebastian Lisken]

Well, I'd like to thank someone but don't know who is responsible. ;-)
This was obviously dependant on some other bug which was resolved before
the link to this one was discovered? Makes me wonder if the bug might
reappear at some time - hopefully not.

Comment 18

[Sebastian Lisken]

I'm sorry, but there is still a sequence of action that produces
this error. See if you get this too, I used 1.6a under Win2K.

1. Load the "slightly extended testcase". The "input 1" field will
   be selected, as it should be.

2. Click on the "Go Somewhere" link.

3. Go back in the history, _using the key sequence_ (Alt+Left under
   Windows).

Result: "input 1" is no longer selected. (You need to use Reload or
Shift+Reload to have it selected again.) This will not occur if I
mouse-click the "Reload" button! I've tried this several times, it's
consistent.

I guess the bug should be reopened.

Comment 19

[Stefan Borggraefe]

Sebastian: This works for me, too (Build 2003102804 on Windows XP). For me it
makes no difference whether I use the keyboard or the mouse for going back.