Closed Bug 85286 Opened 19 years ago Closed 18 years ago

repeated 'password save' and 'security warning' dialogs on page[form sub]


(Core :: DOM: Core & HTML, defect, P2, major)






(Reporter: shrir, Assigned: john)





(1 file, 1 obsolete file)

seen on branch 0607 windows..pls reassign if component is incorrect

go to
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 

xpcted : only one password save dialog should appear
not sure if this is passwd mgr or crypto.
Assignee: pchen → morse
Component: XP Apps → Password Manager
QA Contact: sairuh → tpreston
It's crypto.  Reassigning.
Assignee: morse → ddrinan
Component: Password Manager → Client Library
Product: Browser → PSM
QA Contact: tpreston → junruh
Version: other → 1.01
Worksforme with the latest trunk build.
Version: 1.01 → 2.0
seen on the branch...
2001061414 linux build.
Priority: -- → P2
Target Milestone: --- → 2.0
*** Bug 84823 has been marked as a duplicate of this bug. ***
Mass reassigning target to 2.1
Target Milestone: 2.0 → 2.1
Keywords: nsenterprise
-> P1
Priority: P2 → P1
Assignee: ddrinan → morse
Component: Client Library → Password Manager
Product: PSM → Browser
Target Milestone: 2.1 → ---
Version: 2.0 → other
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.
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.
I believe the old bug that I was thinking of was bug 7858.
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
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.


<form style="margin:0;"
      onSubmit="return setJS();"
  <input type=hidden name=curmbox value=ACTIVE> 
  <input type=hidden name=js value=no> 
  <input type=hidden name="6c6f7264" value=""> 
  <table cellpadding=0 cellspacing=0 border=0 width=100% class=mctbl> 
      <td valign="middle" colspan=3>
        <font face=verdana,sans-serif size=1>Hotmail Member Name:</font>
        <font face=verdana,sans-serif size=1>
          <input type="text" name="login" size="13" maxlength="64">
        <font face=verdana,sans-serif size=1>Password:</font>
        <font face=verdana,sans-serif size=1>
          <input type="password" name="passwd" size="13" maxlength="64">
      <td width=22 valign="middle" align="center">
        <input TYPE=IMAGE
               ID=m BORDER=0
               ALT="Sign in to Hotmail">
      <td colspan=3>
        <a href="P/1/">
          <font face=verdana,sans-serif size=1>Sign up for free e-mail</font>

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.

    function setJS(){

Found the other bug that I was thinking of.  It's 60280.
Here's a much simpler testcase that demonstrates the problem.

    <form name=HotmailForm onSubmit="document.HotmailForm.submit();"> 
      <input type="text">
      <input type="password">
      <input type="submit">
Removing nsenterprise nomination, adding nsBranch.
Keywords: nsenterprisensBranch
sounds more like a pollmann issue, if not send it back
Assignee: rods → pollmann
*** Bug 97085 has been marked as a duplicate of this bug. ***
Eric's not here anymore.  I'll take a look.
Assignee: pollmann → pierre
Target Milestone: --- → mozilla0.9.5

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+
removed keyword nsbranch since it now has nsbranch+, per pdt mtg.
Keywords: nsbranch
any updates on the fix for this?
Pierre is looking at this bug today.
Reassigning to Rod
Assignee: pierre → rods
Summary: multiple 'password save' and 'security warning' dialogs on page → [FIX]multiple 'password save' and 'security warning' dialogs on page
Whiteboard: Fix in hand
Attached patch proposed patch (obsolete) — Splinter Review
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.
Attachment #50579 - Attachment is obsolete: true
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 when you have reviews).  This seems pretty serious (or at
least very annoying)
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 

what am i missing?
-- rick
adding PDT for review
Whiteboard: Fix in hand → Fix in hand, PDT
Whiteboard: Fix in hand, PDT → ETA: 9/27/2001. Fix in hand, PDT
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?
Actually, the comments are there in the "DoSubmitOrReset" method, check those 
Whiteboard: ETA: 9/27/2001. Fix in hand, PDT → ETA: 9/27/2001. Fix in hand, [PDT]
Comment on attachment 50691 [details] [diff] [review]
proposed patch using nsIWebProgressListener
Attachment #50691 - Flags: review+
hey rod,

you're absolutely right!! i'm blind :-)

-- rick
Comment on attachment 50691 [details] [diff] [review]
proposed patch using nsIWebProgressListener
Attachment #50691 - Flags: superreview+
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.
Changes are made, waiting on pdt
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
fixed on tip and branch
Closed: 19 years ago
Resolution: --- → FIXED
Note: this checkin caused Bug 102176, Bug 102345, Bug 102532. So test against 
these now invalid bugs when the new patch is ready.
Keywords: nsbranch+nsbranch
Resolution: FIXED → ---
Summary: [PDT+] [FIX]multiple 'password save' and 'security warning' dialogs on page → multiple 'password save' and 'security warning' dialogs on page
Whiteboard: ETA: 9/27/2001. Fix in hand, [PDT] → ETA: 9/27/2001.
Marking nsbranch-. The potential fix is too risky.
Keywords: nsbranchnsbranch-
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
moving to 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
reassinging to new owner of form submission
Assignee: rods → alexsavulov
Summary: multiple 'password save' and 'security warning' dialogs on page → multiple 'password save' and 'security warning' dialogs on page[form sub]
Blocks: 107067
Keywords: nsbranch-
Removed ETA from status
Whiteboard: ETA: 9/27/2001.
moving to 0.9.7 until rods checks why is still open although is alredy fixed
Target Milestone: mozilla0.9.6 → mozilla0.9.7
Assignee: alexsavulov → rods
I won't get this in until 9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
back to you
Assignee: rods → alexsavulov
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]

will be repaired when 72906 gets repaired
Depends on: 72906
Target Milestone: mozilla0.9.8 → mozilla1.0

this is the same like 72906
Assignee: alexsavulov → jkeiser
Target Milestone: mozilla1.0 → ---
Retargeting to same milestone as bug 72906.
Priority: P1 → --
Target Milestone: --- → mozilla1.0
Marking nsbeta1+
Keywords: nsbeta1+
Priority: -- → P2
Fixed with bug 72906.
Closed: 19 years ago18 years ago
Resolution: --- → FIXED
Blocks: MS
Component: HTML: Form Submission → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.