Closed
Bug 85286
Opened 23 years ago
Closed 23 years ago
repeated 'password save' and 'security warning' dialogs on page[form sub]
Categories
(Core :: DOM: Core & HTML, defect, P2)
Core
DOM: Core & HTML
Tracking
()
VERIFIED
FIXED
mozilla1.0
People
(Reporter: shrir, Assigned: john)
References
()
Details
Attachments
(1 file, 1 obsolete file)
|
(deleted),
patch
|
rpotts
:
review+
kinmoz
:
superreview+
|
Details | Diff | Splinter Review |
seen on branch 0607 windows..pls reassign if component is incorrect
go to msn.com
enter username and password and click GO
On the 'password save' dialog, click NO
Observe a 'security warning' dialog pops up. click OK
Again ,a 'password save' dialog comes up. and another security dialog comes
up.....
xpcted : only one password save dialog should appear
|
||
Comment 1•23 years ago
|
||
not sure if this is passwd mgr or crypto.
Assignee: pchen → morse
Component: XP Apps → Password Manager
QA Contact: sairuh → tpreston
|
||
Comment 2•23 years ago
|
||
It's crypto. Reassigning.
Assignee: morse → ddrinan
Component: Password Manager → Client Library
Product: Browser → PSM
QA Contact: tpreston → junruh
Version: other → 1.01
|
Reporter | |
Comment 4•23 years ago
|
||
seen on the branch...
|
||
Comment 5•23 years ago
|
||
2001061414 linux build.
Confirmed.
P2
Target->2.0
Priority: -- → P2
Target Milestone: --- → 2.0
|
|
||
Updated•23 years ago
|
Keywords: nsenterprise
|
||
Updated•23 years ago
|
Assignee: ddrinan → morse
Component: Client Library → Password Manager
Product: PSM → Browser
Target Milestone: 2.1 → ---
Version: 2.0 → other
|
|
||
Comment 9•23 years ago
|
||
Re-assigning to morse.
Steve: I don't know why you re-assigned this bug to PSM. If you have some
information that it's PSM, please post in the bug. I disabled encrypting
passwords (i.e. don't use PSM) and the problem still happens. The bug is that
you are prompted twice by the Password Manager to remember you're password.
Again, I don't think PSM is part of the mix here.
|
|
||
Comment 10•23 years ago
|
||
This is occuring because onsubmit handler is being called twice. We had a
problem about that in the past so I'll try and see if I can locate the old bug
report on it.
|
|
||
Comment 11•23 years ago
|
||
I believe the old bug that I was thinking of was bug 7858.
|
|
||
Comment 12•23 years ago
|
||
The problem is occuring when the form is being submitted, resulting in the
onsubmit handler being called twice. Reassigning to form-submission.
Assignee: morse → rods
Component: Password Manager → Form Submission
QA Contact: junruh → vladimire
|
|
||
Comment 13•23 years ago
|
||
FWIW, I tried to simplify this by extracting the form from this page and seeing
if it alone demonstrated the problem. It did not. Posting the form here
anyway, just for reference (extracting it was a difficult procedure because of
the bad style in the msn page).
Note however that I did not extract the javascript code (notable the SetJS
routine). That could account for the multiple onsubmits.
<html>
<body>
<form style="margin:0;"
name=HotmailForm
ACTION="https://lc1.law13.hotmail.passport.com/cgi-bin/dologin/"
onSubmit="return setJS();"
method=post>
<input type=hidden name=curmbox value=ACTIVE>
<input type=hidden name=js value=no>
<input type=hidden name="6c6f7264" value="www.msn.com">
<table cellpadding=0 cellspacing=0 border=0 width=100% class=mctbl>
<tr>
<td valign="middle" colspan=3>
<font face=verdana,sans-serif size=1>Hotmail Member Name:</font>
</td>
</tr>
<tr>
<td>
<font face=verdana,sans-serif size=1>
<input type="text" name="login" size="13" maxlength="64">
</font>
</td>
</tr>
<tr>
<td>
<font face=verdana,sans-serif size=1>Password:</font>
</td>
</tr>
<tr>
<td>
<font face=verdana,sans-serif size=1>
<input type="password" name="passwd" size="13" maxlength="64">
</font>
</td>
<td width=22 valign="middle" align="center">
</td>
<td>
<input TYPE=IMAGE
height=17
width=17
ID=m BORDER=0
SRC=http://msimg.com/w/AS_0/go_m.gif
class=srchBtn
ALT="Sign in to Hotmail">
</td>
</tr>
<tr>
<td colspan=3>
<a href="P/1/">
<font face=verdana,sans-serif size=1>Sign up for free e-mail</font>
</a>
</td>
</tr>
</table>
</form>
</body>
</html>
|
|
||
Comment 14•23 years ago
|
||
Yes, it's the javascript that is causing the double submission. Add the
following header to the html sample above and you can demonstrate the problem.
It's because the javascript does an onsubmit. This is very familiar, and it
isn't bug 7858 but some other bug that was reported on this problem. I'll see
if I can find it.
<head>
<script>
function setJS(){
document.HotmailForm.js.value="yes";
document.HotmailForm.submit();
}
</script>
</head>
|
|
||
Comment 15•23 years ago
|
||
Found the other bug that I was thinking of. It's 60280.
|
|
||
Comment 16•23 years ago
|
||
Here's a much simpler testcase that demonstrates the problem.
<html>
<body>
<form name=HotmailForm onSubmit="document.HotmailForm.submit();">
<input type="text">
<input type="password">
<input type="submit">
</form>
</body>
</html>
|
||
Comment 17•23 years ago
|
||
Removing nsenterprise nomination, adding nsBranch.
Keywords: nsenterprise → nsBranch
|
||
Comment 18•23 years ago
|
||
sounds more like a pollmann issue, if not send it back
Assignee: rods → pollmann
|
||
Comment 19•23 years ago
|
||
*** Bug 97085 has been marked as a duplicate of this bug. ***
|
||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.5
|
||
Comment 21•23 years ago
|
||
from http://www.w3.org/TR/WD-script-960208.html
OnSubmit
A submit event occurs when a user submits a form. JavaScript requires you to
return true in the event handler to allow the form to be submitted; return false
to prevent the form from being submitted. This attribute is used only with the
FORM element.
I'm guessing that we are defaulting to returning true for the OnSubmit handler
when an explicit return value has not be specified.
Marking nsbranch+, since double submitting form data can cause serious problems.
Severity: normal → major
Keywords: nsbranch+
|
||
Comment 22•23 years ago
|
||
removed keyword nsbranch since it now has nsbranch+, per pdt mtg.
Keywords: nsbranch
|
||
Comment 23•23 years ago
|
||
any updates on the fix for this?
|
|
||
Comment 24•23 years ago
|
||
Pierre is looking at this bug today.
|
|
||
Updated•23 years ago
|
Status: NEW → ASSIGNED
Summary: multiple 'password save' and 'security warning' dialogs on page → [FIX]multiple 'password save' and 'security warning' dialogs on page
Whiteboard: Fix in hand
|
|
||
Comment 26•23 years ago
|
||
|
|
||
Comment 27•23 years ago
|
||
The basically does this: Sets a variable in the nsHTMLFormElement
object indicating the submit had taken place. That way when the button click
comes thru and asks it to submit again it bails out.
Hitting reload or the back button still works because the nsHTMLFormElement obj
gets newly created each time.
Oops, ok, the patch doesn't work if for some reason the submit times out. The
nsHTMLFormElement needs to be an observer of the submit.
|
|
||
Updated•23 years ago
|
Attachment #50579 -
Attachment is obsolete: true
|
|
||
Comment 28•23 years ago
|
||
|
||
Comment 29•23 years ago
|
||
Please let us know when this has been reviewed and super reviewed. We'd really
like to get this on the PDT radar for inclusion in eMojo (write to
pdt2@netscape.com when you have reviews). This seems pretty serious (or at
least very annoying)
|
||
Comment 30•23 years ago
|
||
hey rod,
the code for adding and removing the nsIWebProgressListener looks fine... But i
don't see where you are resetting the 'submit state' if the document fails to
load...
what am i missing?
-- rick
|
|
||
Updated•23 years ago
|
Whiteboard: Fix in hand, PDT → ETA: 9/27/2001. Fix in hand, PDT
|
|
||
Comment 32•23 years ago
|
||
Rick, the mWebProgress acts like the "submit state", if it is non-null then we
submitting, if it is null then we can submit.
Should I doument that better?
|
|
||
Comment 33•23 years ago
|
||
Actually, the comments are there in the "DoSubmitOrReset" method, check those
out
|
||
Updated•23 years ago
|
Whiteboard: ETA: 9/27/2001. Fix in hand, PDT → ETA: 9/27/2001. Fix in hand, [PDT]
|
|
||
Comment 34•23 years ago
|
||
Comment on attachment 50691 [details] [diff] [review]
proposed patch using nsIWebProgressListener
r=rpotts@netscape.com
Attachment #50691 -
Flags: review+
|
|
||
Comment 35•23 years ago
|
||
hey rod,
you're absolutely right!! i'm blind :-)
-- rick
|
||
Comment 36•23 years ago
|
||
Comment on attachment 50691 [details] [diff] [review]
proposed patch using nsIWebProgressListener
sr=kin@netscape.com
Attachment #50691 -
Flags: superreview+
|
|
||
Comment 37•23 years ago
|
||
Rod, I talked with rpotts, and we both thought it would be better for your stub
functions to return NS_OK, instead of NS_ERROR_NOT_IMPLEMENTED. This will avoid
any possibility of short circuiting the loading process if they are called.
|
|
||
Comment 38•23 years ago
|
||
Changes are made, waiting on pdt
|
|
||
Comment 39•23 years ago
|
||
check it in - PDT+
If you have a list of sites we can test this against, it would good to get them
in the comments of the bug.
Summary: [FIX]multiple 'password save' and 'security warning' dialogs on page → [PDT+] [FIX]multiple 'password save' and 'security warning' dialogs on page
|
|
||
Comment 40•23 years ago
|
||
fixed on tip and branch
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
|
|
||
Comment 41•23 years ago
|
||
Note: this checkin caused Bug 102176, Bug 102345, Bug 102532. So test against
these now invalid bugs when the new patch is ready.
|
|
||
Comment 42•23 years ago
|
||
Marking nsbranch-. The potential fix is too risky.
|
||
Comment 43•23 years ago
|
||
I think that the correct solution would be to change the default action which is
taken after the onSubmit JS handler function finishes. The default (not returned
true and false) should be to cancel the submit.
The form would be submitted because the document.HotmailForm.submit() function
is called.
But I don't know if it wouldn't break any other page (not conforming to
standard) which assumes otherwise.
OS: Windows NT → All
Hardware: PC → All
|
|
||
Comment 45•23 years ago
|
||
reassinging to new owner of form submission
Assignee: rods → alexsavulov
Status: REOPENED → NEW
|
||
Updated•23 years ago
|
Summary: multiple 'password save' and 'security warning' dialogs on page → multiple 'password save' and 'security warning' dialogs on page[form sub]
|
|
||
Comment 47•23 years ago
|
||
moving to 0.9.7 until rods checks why is still open although is alredy fixed
Target Milestone: mozilla0.9.6 → mozilla0.9.7
|
|
||
Comment 49•23 years ago
|
||
I won't get this in until 9.8
Status: NEW → ASSIGNED
Target Milestone: mozilla0.9.7 → mozilla0.9.8
|
||
Comment 51•23 years ago
|
||
WFM 010403 win98. Logging into msn using my hotmail account gives me "entering
encrypted area" followed by "leaving encrypted area".
Summary: multiple 'password save' and 'security warning' dialogs on page[form sub] → repeated 'password save' and 'security warning' dialogs on page[form sub]
|
|
||
Comment 52•23 years ago
|
||
retargeting
will be repaired when 72906 gets repaired
Depends on: 72906
Target Milestone: mozilla0.9.8 → mozilla1.0
|
|
||
Comment 53•23 years ago
|
||
john:
this is the same like 72906
Assignee: alexsavulov → jkeiser
Target Milestone: mozilla1.0 → ---
|
Assignee | |
Comment 54•23 years ago
|
||
Retargeting to same milestone as bug 72906.
Priority: P1 → --
Target Milestone: --- → mozilla1.0
|
|
||
Updated•23 years ago
|
Priority: -- → P2
|
|
Assignee | |
Comment 56•23 years ago
|
||
Fixed with bug 72906.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
|
||
Updated•6 years ago
|
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in
before you can comment on or make changes to this bug.
Description
•