twilson wrote:

Some further checking reveals a pattern of 400 errors using Firefox on some sites by a number of users. Suggestions to fix the problem include clearing the cache and cookies, which work for some, although for Mediawiki, that would bypass the session and require me to log in, which has never been a problem. (My 400s only come during Save/Preview.)

So, maybe something to do with the way cookies are being set? Or maybe a bug in Firefox? (I'm using 3.6.13.)

Created attachment 8222
Contents of http://dpaste.org/MhTU/

This seems like it could be caused by a Firefox extension. What do you have installed?

Attached:

twilson wrote:

List of firefox extensions

Attached:

It looks like you might also try setting up a new profile.

http://the-edmeister.home.comcast.net/~the-edmeister/tips-html/tips-restoring_your_browsing_data.html
http://frankkoehl.com/2009/04/fixing-firefox-gmail-400-bad-request/

Maybe you can use the CLI sqlite utility to test your cookies file?

twilson wrote:

I've looked at the cookie database (I use sqlitebrowser instead of the CLI), and didn't see anything unusual, although I'm not sure what I'm looking for. Before I go recreating my whole profile, I wonder what the explanation might be for one aspect of my experience, noted in the original report: after getting a 400, clicking "Back" on my browser and resubmitting INVARIABLY results in success, even though the headers (including cookies) and posted data are identical, as reported by LiveHTTPHeaders.

re sqlite use: use the browser to backup/dump the database and remove your profile (after assuring yourself that you can recreate it using the backup).

After you remove the profile, try to reproduce the error. If it doesn't show up, it is the fault of the profile. If it shows up with a new profile, well, then we have a real bug.

Todd: Is this still an issue?

Does the problem still happen if you start Firefox in Safe Mode? (Safe Mode disables extensions and themes, hardware acceleration and some JavaScript stuff in order to exclude some possible reasons for problems. It does not disable plugins which are add-ons.) See http://support.mozilla.com/en-US/kb/Safe+Mode

And does this also happen with a new and empty profile? See http://support.mozilla.com/en-US/kb/Basic%20Troubleshooting#w_8-make-a-new-profile and http://support.mozilla.org/kb/Managing%20profiles .

If you still see this problem in the new profile, please enter the address "about:support" in the address bar and attach (using the "Add an attachment" link above) the output for your original profile (not the new profile), as the "Modified Preferences" section could be interesting.
Thanks for your help!

Unfortunately closing this report as no further information has been provided.

Todd: Please feel free to reopen this report if you can provide the information asked for in comment 7, and if this still happens in a recent and supported MediaWiki version. Thanks!

twilson wrote:

Sorry, I had forgotten about my bug report and, in the meantime, switched to Chromium, where I haven't had the problem. If others develops the problem on Firefox and find this, then perhaps they will be led to try the "remove profile" solution themselves and report. Thanks!