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

RESOLVED WORKSFORME

Status

()

Core
DOM: Core & HTML
RESOLVED WORKSFORME
16 years ago
15 years ago

People

(Reporter: tessarakt, Unassigned)

Tracking

({regression})

Trunk
x86
Windows 2000
regression
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
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

16 years ago
Created attachment 110014 [details]
testcase

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

Comment 2

16 years ago
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
Assignee: alexsavulov → jst
Status: UNCONFIRMED → NEW
Component: Form Submission → DOM Level 0
Ever confirmed: true
QA Contact: vladimire → desale

Updated

16 years ago
Keywords: regression

Comment 3

16 years ago
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

16 years ago
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

16 years ago
Created attachment 114222 [details]
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).
Mass-reassigning bugs to dom_bugs@netscape.com
Assignee: jst → dom_bugs

Comment 7

15 years ago
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

15 years ago
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
We should get some traction on this.
Severity: enhancement → normal
Keywords: nsbeta1

Comment 10

15 years ago
adt: nsbeta1-
Keywords: nsbeta1 → nsbeta1-

Comment 11

15 years ago
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

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

Comment 13

15 years ago
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

15 years ago
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

15 years ago
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

15 years ago
Marking WFM.
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → WORKSFORME

Comment 17

15 years ago
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

15 years ago
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

15 years ago
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.
You need to log in before you can comment on or make changes to this bug.