344420 - Form cannot be resubmitted after back button used after submit

Status: RESOLVED INCOMPLETE

(SeaMonkey :: General, defect)

Description

[Charles Schultz]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060516 SeaMonkey/1.0.2
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8.0.4) Gecko/20060516 SeaMonkey/1.0.2

Mozilla 1.7 and earlier had a feature I often used when submitting forms multiple times with partial changes. After submitting a form, I could hit the brouser back button  to change items as needed and submit the form again. In Seamonkey and Firefox this no longer works. Hitting submit after backing up to alter the entries not longer sneds the form.

Reproducible: Always

Steps to Reproduce:
1.Fill out form
2.Submit form
3.Hit back button
4.Filled out form re-appears
5.Edit form entries
6.Submit form
7.Form not sent in Seamonkey or Firefox. Form sent in Mozilla


Actual Results:  
Mozilla sends the form and the process can be repeated.
Seamonkey and Firefox does nothing.

Expected Results:  
Form should be submitted

Comment 1

[Frank Wein [:mcsmurf]]

Do you see any errors in the JavaScript Console (Tools->Web Development in SeaMonkey) when trying to re-submit the form? Is this a problem with all web forms for you or only with a specific one?

Comment 2

[Charles Schultz]

(In reply to comment #1)
> Do you see any errors in the JavaScript Console (Tools->Web Development in
> SeaMonkey) when trying to re-submit the form? Is this a problem with all web
> forms for you or only with a specific one?
> 
No known JavaScript errors. Not sure about other forms.
I have found a workaround of clicking on reload after hitting the back button.

Comment 3

[Frank Wein [:mcsmurf]]

One form is for example http://www.cs.tut.fi/~jkorpela/forms/form1.html and that one works for me. What form/website did you use to test this?

Comment 4

[Charles Schultz]

You are right that the sample form you provided works.
The forms in question are assessment scheduling forms in the Cisco Academy CCNA curriculum. By backing into the time/date form, I can change the selected assessment dates without having to re-enter the assessment selections and times. The forms are secure to Cisco so I cannot allow you access. There is some javascript in the form. 

As noted above, the scenario works if I reload the form after backing into it.
There must be a difference in hou Mozilla and Seamonkey decide on refreshing the form.

Comment 5

[Frank Wein [:mcsmurf]]

Maybe it's related to the new Fastback feature (that is when you click on the Back/Forward button it's much faster in SeaMonkey 1.0 compared to Mozilla 1.7)? Can you go to the URL about:config and change the value of browser.sessionhistory.max_total_viewers to 0? Just enter "browser.sessionhistory.max_total_viewers" in the filter field at the top and then doubleclick the entry in the area below to change it. Now try to reproduce this bug here again, if it's not possible then this is probably related to the new Fastback feature and possibly the website uses some JavaScript on Submit. If you want to change that pref back to the default value, just right click on it and click on "Reset".

Comment 6

[Darcy Krasne]

I'm having the exact same problem.  I tried changing the value, as suggested, and that worked temporarily, but as soon as I quit out of Firefox and came back, the problem was back.  I tried resetting the value and changing it to zero again, but it didn't work this time.

Examples of other forms that have this issue (besides the one Charles was having trouble with) are Google maps (maps.google.com) and The Scrabble Rack (www.boulter.com/scrabble).  Note that in both these cases, the form response loads onto the same page.

Comment 7

[Jeremy McCracken]

This bug is described in another report, #314600. To see it, go to google, enter something and hit search, then hit back. Now the submit button and enter key do nothing. Also, hitting the stop button before the next page has a chance to load will trigger this.

Comment 8

[Andrew Schultz]

if disabling fastback, then I'm not really sure what SeaMonkey can do to help you.  You can reload the page after you go back (or just select the URL in the location bar and hit enter).

Comment 9

[Darcy Krasne]

Reloading the page totally doesn't work when the problem is with, say, Google maps, which always just has maps.google.com in the address bar, and will reload to that. Very, very, very annoying, I assure you.

Comment 10

[Charles Loosen]

See similar reports:  #316838 , #309993 , #408044

Comment 11

[Paul Laferriere]

I was having this problem too with (1) www.google.com and most annoyingly with (2) maps.google.com.  I tried setting browser.sessionhistory.max_total_viewers to 0 as suggested above, which worked for (1) but not for (2).  Today I decided to pursue the issue further, and launched Firefox with a clean profile.  The problem wasn't there!  I suspect the issue was caused by one of the extensions I had installed--perhaps something altering javascript handling.  Maybe it was Grease Monkey, maybe something else, I don't know.  I wasn't really using these extensions, so I've uninstalled all of them except Adblock, and I'm happily using my old profile, with browser.sessionhistory.max.total_viewers set back to -1.

Comment 12

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008041201 SeaMonkey/2.0a1pre

I'm retyping the bug numbers mentioned above so that they appear as links:
comment #7: bug 314600
comment #10: bug 316838, bug 309993, bug 408044

Seeing how many different people have been bit by this bug, I suppose I can confirm it.

On http://maps.google.com/ hitting Back gives me the empty form: what I filled-in is lost. On other sites (such as http://bugzilla.mozilla.org/ and its various pages IIRC), what I typed is still there. I don't remember ever seeing the exact behaviour mentioned in comment #0.

browser.sessionhistory.max_total_viewers is at its default, -1.

Comment #11 seems to imply that this bug is due to some extension(s). Should we close it INVALID or pursue it further?

Comment 13

[Darcy Krasne]

As regards comment #11, it could conceivably have been Greasemonkey that triggered the bug initially, but removing it (and my other extensions) and doing a clean install didn't fix the bug in my case.

Comment 14

[Joanna Dionne]

I'm not a  power user, and complex work arounds are really unacceptable.  I have this problem routinely.  Most recent irritation - trying to enter books in Library Thing.  This problem recurs at every turn.

Comment 15

[Serge Gautherie (:sgautherie)]

Can you reproduce with SeaMonkey v1.1.9 ?

Comment 16

[Stéphane Grégoire (yamo)]

Charles, could you give an url where this bug append?

It's a very strange bug!

I've done like https://bugzilla.mozilla.org/show_bug.cgi?id=344420#c7 and with Mozilla/5.0 (X11; U; Linux i686; fr-FR; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9 (Ubuntu-1.1.9+nobinonly-0ubuntu1) I didn't see any bug.

I've also tested :http://www.cs.tut.fi/~jkorpela/forms/form1.html and I'ven't seen any bugs!

Comment 17

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #11)
> (1) www.google.com and most annoyingly with (2) maps.google.com.
>  I tried setting browser.sessionhistory.max_total_viewers to 0 as suggested above,
> which worked for (1) but not for (2).

(In reply to comment #12)
> On http://maps.google.com/ hitting Back gives me the empty form: what I
> filled-in is lost.

Bug 408044 is for issue with maps.google.com, and is different from other bugs (problem disappears when browser.sessionhistory.max_total_viewers=0 is set).
See dependency tree for meta Bug 415889.

(For this bug, phenomenon described in Comment #0)
Because of next, I can't imagine other case than similar case to Bug 309993/Bug 314600.
(A) If FORM is something like <form onSubmit="submit_button.disabled=true;">, and if max_total_viewers!=0 is set, phenomenon like bug summary can occur, and max_total_viewers=0 is an workaround.
(See Bug 309993, Bug 314600. See also meta Bug 415889 Comment #2.)
(B) Mozilla didn't have bfcache. Firefox(then Seamonkey too) has bfcache. 
(C) Bug opener says as follows in comment #4.
> the scenario works if I reload the form after backing into it

However, no one can say whether this bug(problem of comment #0) is "problem when max_total_viewers=-1 and submit_button.disabled=true" or not, until really used HTML upon comment #0 is provided by bug opener. No one can say whether this bug is Dup of Bug 309993(or Bug 314600) or not, without evidence.

Comment 18

[Tony Mechelynck [:tonymec]]

Resolving INCOMPLETE according to:
- comment #17
- lack of reply to comment #16 after 1½ months
- lack of reporter's reply to comment #15 after 2 months.

Charles (reporter), you can REOPEN if you supply the information requested.