538977 - Form data frequently lost during submission

Status: RESOLVED DUPLICATE of bug 547239

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

Description

[Colin Guthrie]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2) Gecko/20100109 Mandriva Linux/1.9.2-0.rc1.1mdv2010.1 (2010.1) Firefox/3.6
Build Identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2) Gecko/20100109 Mandriva Linux/1.9.2-0.rc1.1mdv2010.1 (2010.1) Firefox/3.6

When filling in some form details I've frequently been hit by a bug whereby the form is apparently submitted, but the data therein is apparently invalid. The website in question will reply with an error which normally means I hit "back" and try the form again, sadly the back button does not work - whatever causes FF to not submit the form data correctly also seems to break the inclusion of the submitting page in the history.

This is easiest to reproduce when clicking on a link from an external application directly to the page you will ultimately fix.

I can reproduce this with "ZenDesk" (www.zendesk.com) quite easily. I originally reported this to ZenDesk thinking it was a bug in their AJAX code but I have since seen the same behaviour on a site that does not use AJAX for any form submission related functionality and yet the same problem occurred (this other site was using Trac from Edgewall)

Usually I can avoid the problem by reloading the page prior to filling in the form, but this is not totally infallible. This is a very annoying problem and I've lost quite a lot of data as a result (there is no way to recover the lost form entries :(). IMO it's a 3.6 blocker.

Reproducible: Sometimes

Steps to Reproduce:
1. Load a site that uses a form from a direct link in e.g. thunderbird.
2. Fill in form and submit.
3. Get server specified error due to form fileds not being included in the form submission.
4. Note that the history is totally blank meaning that whatever just happened did not actually record the previous page in the history system.
Actual Results:  
Form Submission should succeed and the history of your browsing session updated so that hitting back would take me back to the original page.

Expected Results:  
Form submission fails (obviously server side determines what error is shown). "Back" button does not include the history of the previous page.

I've been seeing this in previous betas but it's still present in RC1.

On a related note, I do not seem to be able to submit any forms with file upload widgets on them.... (while I'm not certain, this could be the trigger case).

Comment 1

[Colin Guthrie]

Still present in RC2

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2) Gecko/20100119 Mandriva Linux/1.9.2-0.rc2.2mdv2010.1 (2010.1) Firefox/3.6

Comment 2

[Colin Guthrie]

I'm still seeing this in 3.6 final.

Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9.2) Gecko/20100125 Mandriva Linux/1.9.2-2mdv2010.1 (2010.1) Firefox/3.6

I've done some more debugging and put some code into the development version of the website I develop to catch this scenario.

I'll attach some debug files.

Comment 3

[Colin Guthrie]

Attachment: The apache request headers when this problem occurs

This is the result of the PHP apache_request_headers() when this problem occurs. I've removed the cookies but they appear to be valid.

This clearly shows a Content Length of 0 being passed in. While this is from my development system, the symptoms have been noted in the wild on random websites.

Does anyone have any idea what the problem could be? It seems like a pretty serious issue, but if it was a wider problem I'd expect it would have been noticed by now :s

Comment 4

[Colin Guthrie]

I should have mentioned above, but doing a:
 file_get_contents('php://stdin');
when the problem occurs also results in empty data (so the content-length header is at least correct when it says 0... even if there should be *some* post data in there...

Comment 5

[Colin Guthrie]

For reference I've disable all addons with the exception of my theme and the British English dictionary and the problem still occurs (that rules out e.g. a Firebug/Adblock problem).

I'll try with a totally clean profile next.

Comment 7

[Colin Guthrie]

From the other bug report it seems as if this is a profile issue as I was beginning to expect (see my last comment!). I've had success with a clean profile too, but I've kept my original profile to aid debugging.

Is there anything specific I should edit to try and narrow down the problem. I can do a "bisect" on prefs.js to narrow down the problematic entries if that would help?

Comment 8

[Boris Zbarsky [:bzbarsky]]

Colin, what are your proxy preferences set to?  If it's not "no proxy", chances are this is effectively bug 547239.

Comment 9

[Colin Guthrie]

Indeed I've not got any proxy setup here. I never see a 307 redirect message and in some software under my control I'm pretty confident I do not generate any 307's anyway, but I'll try and test out that patch all the same. Thanks for pointing out the other bug.

Comment 10

[Boris Zbarsky [:bzbarsky]]

Colin, does that mean that your preferences are set to "no proxy"?  Or just that you have no actual proxy set up?

Comment 11

[Colin Guthrie]

Actually, looking more closely, it was set to "Auto-detect proxy settings for this network" (4 IIRC).

I've now reset the value to 0 (Use system proxy settings) and I'll see how it goes.

Comment 12

[Mike Beltzner [:beltzner, not reading bugmail]]

How'd it go? I'm clearing the flagss for now, please renominate if we can figure out what's causing this.

Dao: why did you mark this as confirmed - do you have STR?

Comment 13

[Dão Gottwald [:dao]]

I confirmed it because I've seen it myself, heard about it from others, and there's a duplicate. I don't have STR.

Comment 14

[Colin Guthrie]

I don't recall seeing this problem since clearing out any custom proxy settings, so I think whatever causes the issue relating to them is likely the same problem. I meant to update this bug before now, so apologies for needing a prompt.

Comment 15

[Dão Gottwald [:dao]]

I also haven't seen this for a while, so I guess this really is bug 547239. If anyone is still affected with Firefox 3.6.2+ or a recent trunk build, please reopen.