Closed
Bug 214745
Opened 21 years ago
Closed 20 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•21 years ago
|
||
|
|
||
Comment 2•21 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•20 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•20 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•20 years ago
|
||
Resolving as WORKSFORME
Status: UNCONFIRMED → RESOLVED
Closed: 20 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•