Closed
Bug 214745
Opened 22 years ago
Closed 21 years ago
javascript focus method fails
Categories
(Core :: DOM: Core & HTML, defect)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: ventura, Unassigned)
Details
Attachments
(1 file)
487 bytes,
text/html
|
Details |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030718
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5a) Gecko/20030718
This is xhtml example code
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN"
"DTD/xhtml1-transitional.dtd">
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" />
<title>Bug?</title>
</head>
<body>
<form name="aform">
<input name="i1" type="text" tabindex="1"
onchange="javascript:document.aform.i3.focus();" />
<input name="i2" type="text" tabindex="1" />
<input name="i3" type="text" tabindex="1" />
</form>
</body>
</html>
Reproducible: Always
Steps to Reproduce:
1.write something in i1
2.press tab key
Actual Results:
cursor is blinking on i3, but i write on i2
Expected Results:
I should write on i3
Comment 1•22 years ago
|
||
Comment 2•22 years ago
|
||
> onchange="javascript:document.aform.i3.focus();"
Don't know whether this belongs in Event Handling, DOM, or elsehwere.
But it doesn't belong in JavaScript Engine, which is has no notion of
events or focus. Reassigning to DOM for further triage -
Assignee: rogerl → dom_bugs
Component: JavaScript Engine → DOM Level 0
QA Contact: pschwartau → ashishbhatt
Comment 3•21 years ago
|
||
Hi.
I have Mozilla/5.0 (X11; U; Linux i686; es-ES; rv:1.4) Gecko/20030624 from Nave
project (spanish) in RH 7.1, and this testcase work fine for me if I use enter
key, but it works bad widht tab key.
If I user tab key, the cursor and (aparentely) the focus goes to i2, no i3, when
with enter key, aparentely, the cursor and focus goes to i3.
Thanks.
Eduardo
Comment 4•21 years ago
|
||
Hi:
I don't know the code, but it looks like the tab key do something like:
tab_pushed{
where_go = next_field_in_page;
do_on_blur{something, something, something},
do_on_change(something, document.page.elsewhere.focus(); something),
do_on_fooo;....
document.page.where_go.focus();
}
Is it possible that? And then, is it possible to rewrite where_go with
document.page.elsewhere when focus() is used?
thanks.
Comment 5•21 years ago
|
||
The reporter's testcase works as expected with Mozilla 1.6 build 20040113.
But when trying the reporter's testcase with Firebird 0.7 rv:1.5 20031007, then
the cursor is blinking in the 3rd input (i3) and as soon as typing occurs, the
2nd input (i2) is edited.
Best would be to try the testcase with very recent Mozilla and Firebird builds
before confirming for either Mozilla and/or Firebird.
"be sure that you've reproduced your bug using a build released within the past
three days. Our development process moves at lightning speed, and the bug you've
found may already have been fixed."
http://www.mozilla.org/quality/bug-writing-guidelines.html
XP Pro SP1 here.
Comment 6•21 years ago
|
||
The reporter's testcase works correctly (I get the expected results) in the
latest available nightly build of Firebird rv:1.7a Gecko/20040120 Firebird/0.8.0+.
XP Pro SP1 here.
Comment 7•21 years ago
|
||
In FireFox 0.9.1 under Windows XP, this works as expected. However, I came
across another curiousity: If I type something in i1 and then CLICK on i2, the
focus changes to i3. I have to click a second time to change the focus to i3.
However, whether I clicked or tabbed my way through the fields, my text input
properly appeared in the textbox with the blinking cursor every time.
Comment 8•21 years ago
|
||
The testcase works for me, Firefox 0.9.1 WinXP SP1. Here's a complete analasys:
Opened the attachment with the testcase. Pressed Tab until the first text box
got selected. Typed "Testing". Pressed tab, focus went to 3rd text box. Typed
"123". Pressed tab a few more times until the second text box finally got
selected, typed "Tap tap tap". Text goes to the textbox that the cursor is
flashing in. However, on the first cycle, skips the second text box. Maybe
coding bug?
Comment 9•21 years ago
|
||
Resolving as WORKSFORME
Status: UNCONFIRMED → RESOLVED
Closed: 21 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•