189149 - Password manager is not associated with active window allowing website to close after a submit button is clicked but before password can be saved.

Status: RESOLVED EXPIRED

(SeaMonkey :: Passwords & Permissions, defect)

Description

[Sam Katz]

User-Agent:       Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.3b) Gecko/20030114
Build Identifier: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:1.3b) Gecko/20030114

Logging in to the site with Mozilla 1.3 2003011412 causes the login window to
close without the form being submitted. This is because the password manager
pops up after the form is submitted, and does not take precedence over the
javascript that closes the window as outlined in
http://download20fp.netacad.net/contentassets/js/global.js
(I believe it works on a timer as specified in references:
http://developer.irt.org/script/84.htm)

In addition, in Phoenix, a security box (unencrypted information) also pops up,
and the timer seems shorter. (I know this is not the right report for that, but
I can't file dupes..)
 

Reproducible: Always

Steps to Reproduce:
1. Go to URL.
2. Click Login.
3. Enter a username and password (it doesn't matter, the login will fail.)
4. Click Go.
5. Password Manager pops up (and on phoenix, even if the password is stored, a
security box will still pop up.)
6. without waiting or allowing sufficient time for user input, window closes.
7. submission of fourm is prevented.


Expected Results:  
Mozilla should associate the password managers' dialogs and security-related
dialogs (which only happened in phoenix..) with the active window. It should
halt all javascript actions to that window. (after all, the security window pops
up in case you want to stop a potential transaction.)

Workaround: If you press enter to the dialog boxes before the time-out
(difficult), then you get results in the main window. (ie. if you have an
invalid login, it will tell you, or it will log you in.) It will submit the
fourm and everything else in the globals.js works great.  The password is then
saved. You should use the password manager to remove this info to retest the bug.

You may also view my explanation of the code on the main page here:
http://www.mozillazine.org/forums/viewtopic.php?t=4302

Summary for convenience: It was the opinion of members of the Mozillazine
Phoenix Fourm that the code was compliant. 
upping the priority to major as password manager does break..
Sam

Comment 1

[alanjstr]

Please try to simplify the code as much as possible.  Also, I do not think this
is major, since a lot of people are not affected.  Why is OS set to Other?

Comment 2

[Sam Katz]

I can perhaps configure a test site later. A test site would contain:
a window that opened another window, with timeout directive.
The window spawned would contain a password field. Is this sufficient?

Comment 3

[Sam Katz]

I need help creating a sufficient test case. 

I can get the security dialog to popup, and can actually turn it off.

We are developing a very good workaround.

1. go to site.
2. login.
3. password manager will popup.
4. press enter, and it will remember the username and password.
5. security warning will popup, and close window. (phoenix only)
6. To work around this, go to www.paperlessconscience.com/test.html (my site),
and click the submit button (the form contains a password field - any action
attribute), You will be presented with a security box. This time you should be
able to uncheck the box. This then applies to all sites, including the cisco site.
7. Now logins work flawlessly.

Issues:
*If you look at the source code for my test page, I try to produce something
that will close the window, and present a password manager. I cannot do this
yet. I learn Javascript as I need it. But, what triggers the password manager,
and why won't the window close?
* Is this now a cisco bug? I don't think we have enough information to confirm that.
Sam

Comment 4

[Sam Katz]

This may have something to do with Mozilla's security policy that scripts have 
ultimate power to close windows they create. (although the bug below is 
discussing the reverse issue, where scripts aren't allowed to close windows 
they don't create).

This bug does not occur in Opera.. just FYI..I know its closed source. 

http://bugzilla.mozilla.org/show_bug.cgi?id=178183

Comment 5

[Gervase Markham [:gerv]]

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/

Comment 6

[Gervase Markham [:gerv]]

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.