Changing focus from the results of a Confirm box fails

RESOLVED DUPLICATE of bug 53579

Status

()

--
major
RESOLVED DUPLICATE of bug 53579
16 years ago
8 years ago

People

(Reporter: anopres, Unassigned)

Tracking

Trunk
x86
Windows XP
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

16 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4a) Gecko/20030401

When working with the result of a Confirm box (or an alert box) to change the
focus of a form, the focus is always changed to the next control on the form
instead of the intended control.

Reproducible: Always

Steps to Reproduce:
1. Tab through the fields on the test form and click the "ok" button on the
confirm box.


Actual Results:  
The focus moves to the next field regardless of the intended destination.  The
proper field can still be operated on, however.

Expected Results:  
Mozilla should return focus to the intended control instead of the next field in
the form.
(Reporter)

Comment 1

16 years ago
Created attachment 121431 [details]
Demonstration of the issue.

Comment 2

16 years ago
This is still a problem and there are several bugs that demonstrate that focus
from alert and confirm boxes are not correctly restored.

It works if you do an onchange event on field a which sets focus to itself if
the value is invalid.   Change the value of field a, hit tab , and confirm or
close the dialog box.  Notice the focus is not on the fired element but has
automatically bet set to the next form element.

This is a major useability issue and the new stable base 1.4 shouldn't ship with
this flaw.   We have many dynamic forms, and they are unuseable in Mozilla.  Of
course, that's only my 2c. 

Comment 3

14 years ago
Created attachment 171956 [details]
Corroboration for Firefox v1.0

This bug is readily reproducable in Firefox v1.0 (latest test with Mozilla/5.0
(Windows; U; Win98; en-US; rv:1.8b) Gecko/20050119 Firefox/1.0+). Please see my
attachment for more information.

Comment 4

14 years ago
Comment on attachment 171956 [details]
Corroboration for Firefox v1.0

><HTML><HEAD><TITLE>Link to Mozilla bug 203054 demo</TITLE></HEAD>
><BODY>
>I have fully documented test cases for Bugzilla's bug #
>203054 at <A href="http://www.pagestep.com/_dev/bugzilla/203054/test.php">www.pagestep.com/_dev/test.php</A>.<BR/>
><BR/>
>I can be reached at
><A href="mailto:dirk@pagestep.com">dirk@pagestep.com</A>
></BODY></HTML>

Comment 5

14 years ago
Comment on attachment 171956 [details]
Corroboration for Firefox v1.0

><HTML><HEAD><TITLE>Link to Mozilla bug 203054 demo</TITLE></HEAD>
><BODY>
>I have fully documented test cases for Bugzilla's bug #
>203054 at <A href="http://www.pagestep.com/_dev/test.php">www.pagestep.com/_dev/test.php</A>.<BR/>
><BR/>
>I can be reached at
><A href="mailto:dirk@pagestep.com">dirk@pagestep.com</A>
></BODY></HTML>

Comment 6

14 years ago
Ignore last couple of comments; I wanted to update the link to the attachment,
but this is apparently impossible, or beyond my ken. What gives, guys? :-(
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
This bug has been automatically resolved after a period of inactivity (see above
comment). If anyone thinks this is incorrect, they should feel free to reopen it.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → EXPIRED
(Reporter)

Comment 9

13 years ago
This appears to still be a problem.
Status: RESOLVED → UNCONFIRMED
Resolution: EXPIRED → ---

Comment 10

13 years ago
The onchange handler may be the wrong place to call focus (see bug 243816).  If so, this looks like a dupe of bug 53579.

Comment 11

13 years ago
(In reply to comment #10)
> The onchange handler may be the wrong place to call focus (see bug 243816).  If
> so, this looks like a dupe of bug 53579.

I was not aware that Javascript disallowed calling focus() from an onchange handler. Clarifications anyone?

PS This is now confirmed using Firefox 1.0.7 on Win98SE.
Assignee: saari → nobody
QA Contact: desale → events
Attachment #171956 - Attachment is obsolete: true
Looks a lot like bug 53579...
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 53579
You need to log in before you can comment on or make changes to this bug.