Submit Button Broken After First Submit

VERIFIED INVALID

Status

()

Core
HTML: Form Submission
P1
blocker
VERIFIED INVALID
16 years ago
16 years ago

People

(Reporter: Robert Rainwater, Assigned: rods (gone))

Tracking

({regression, smoketest, top100})

Trunk
mozilla0.9.5
regression, smoketest, top100
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [critical for 0.9.5], URL)

Attachments

(1 attachment)

(Reporter)

Description

16 years ago
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.

Comment 1

16 years ago
confirmed WinMe 2001092803
Google.com, groups.google.com 
Severity: normal → blocker

Comment 2

16 years ago
really confirming this time
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 3

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

Updated

16 years ago
Blocks: 101793

Comment 4

16 years ago
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.
Keywords: nsbranch, regression, smoketest, top100
*** Bug 102174 has been marked as a duplicate of this bug. ***

Comment 10

16 years ago
can someone comment on whether this is on the branch. if it is on the branch,
pls nsbranch+ this one.
Whiteboard: [critical for 0.9.5]

Comment 11

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

Comment 12

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

Updated

16 years ago
OS: Windows ME → All
Hardware: PC → All

Comment 13

16 years ago
This was probably caused by the fix for 85286.

Comment 14

16 years ago
Looks like it's only broken when the result of the submit is loaded in a new 
window.
(Reporter)

Comment 15

16 years ago
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.
(Assignee)

Comment 17

16 years ago
Created attachment 51517 [details] [diff] [review]
proposed patch
(Assignee)

Comment 18

16 years ago
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.
Status: NEW → ASSIGNED
Priority: -- → P1
Summary: Submit Button Broken After First Submit → [FIX]Submit Button Broken After First Submit
Target Milestone: --- → mozilla0.9.5
(Assignee)

Comment 19

16 years ago
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.

Comment 20

16 years ago
Please see bug 102345 for information on how this applies to
http://www.google.com/search?q=mozilla (slightly different problem)
Marking nsbranch+.
Keywords: nsbranch → nsbranch+

Comment 22

16 years ago
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......
(Assignee)

Updated

16 years ago
Summary: [FIX]Submit Button Broken After First Submit → Submit Button Broken After First Submit

Comment 23

16 years ago
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.
(Assignee)

Comment 24

16 years ago
The patch causing this problem has been removed - invalid
Status: ASSIGNED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → INVALID
*** Bug 102673 has been marked as a duplicate of this bug. ***

Comment 26

16 years ago
verifying
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.