User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.4+) Gecko/20010928 BuildID: 2001092803 After using a submit button, it appears that the button no longer functions when trying to use it again. Reproducible: Always Steps to Reproduce: 1. Go to http://sourceforge.net 2. Enter a search term in the search box and submit 3. Go back to the original browser window 4. Enter another search term and submut 5. Nothing happens the second time Actual Results: The submit button does not perform any action. This appears to happen on many other sites as well.

confirmed WinMe 2001092803 Google.com, groups.google.com

really confirming this time

I'm seeing this as well on Linux with build 2001-09-27-21. I tried google.com and saw the bug.

Rods, is this likely to be caused by your checking to bug 99920?

*** Bug 102345 has been marked as a duplicate of this bug. ***

From duped bug 102345 this is not limited to just submitting twice. If you do a GET to a page which is generated by a submit, for example http://www.google.com/search?q=mozilla then we have the same problem described here.

*** Bug 102397 has been marked as a duplicate of this bug. ***

This breaks smoketest B27 - using bugzilla. There doesn't appear to be a plain "using forms" smoketest, although this probably breaks the wallet tests, I guess. Sprinkling magic keyword dust based on the assumption that this went into the branch.

*** Bug 102174 has been marked as a duplicate of this bug. ***

can someone comment on whether this is on the branch. if it is on the branch, pls nsbranch+ this one.

Yes, this problem occurs on 0.9.4 build 2001092905 on Mac OS X.

Submit doesn't work after a form is reset either. see bug 102345

This was probably caused by the fix for 85286.

Looks like it's only broken when the result of the submit is loaded in a new window.

Nope, check http://www.google.com/search?q=mozilla I don't think it is just a new window problem.

http://www.google.com/search?q=mozilla also has two submit buttons, so its a slightly different test case.

The WebProgress is NOT notified when a different window is targeted, so if it is targeted to "_blank" we do not set up a listener. This means with the fix above, if you target a new window and if you click real fast you can get double submits or if the onsubmit handler has a submit you will also get two windows. The above to issues could be fixed with a timer. Meaning we only set up a timer if the target is set to "_blank" otherwise we use the WebProgress.

After talking to Kin, this isn't quite right either. The target could be the name of the window that the form is in. The real solution is to register as a listener to "target" webprogress, how ever that could be made to happen.

Please see bug 102345 for information on how this applies to http://www.google.com/search?q=mozilla (slightly different problem)

Marking nsbranch+.

The tree is currently being held close for this. From reading the bug comments it sounds like we don't have a fix even though the summary says [FIX]. Rod am I understanding you write when you say the patch posted here isn't the right solution? If that's true can we invalidate this patch and remove FIX from the whiteboard. Also, are we sure this bug effects branch builds? Kevin, you gave this a branch+ but I haven't seen anyone actually say they see it on the branch. The branch builds past smoketests today where the trunk didn't because of this bug. Just trying to get a better understanding of this bug so we can get the tree open and to gain some insight on how this may effect the branch......

FYI the http://www.google.com/search?q=mozilla URL does a form reset after the page loads so it is triggering bug 102532 which is slightly different. The problem this bug points out is that the web progress listener isn't being removed when the results of the form submission are loaded in a different window or frame. I also noticed that we aren't removing the listener if I cancel out of the form submission warning dialog. I think rods is going to back out his double submit patch from the branch and trunk to get the tree open again.

The patch causing this problem has been removed - invalid

*** Bug 102673 has been marked as a duplicate of this bug. ***

verifying