STR: - submit a change to a bug, get the process_bug.cgi POST response - close browser - load browser Expected behaviour: - page contents restored from cache if present, OR interstitial resubmit warning prior to POST being resubmitted, OR message saying that the page isn't available because resubmitting would hurt Observed behaviour: - URL is loaded as a GET, giving you an ugly error message on Bugzilla; on some other software (such as some Rails-based apps, if I understand correctly) it could do the equivalent of an un-parameterized delete Unintended GET caused a lot of people to get very angry with Google's web accelerator, due to data loss in unsuspecting applications. If we changed the prefs with respect to things like SSL-page caching in FF3, then we should probably treat this as not quite the same as what was shipped in FF2, since SSL pages are more likely to be associated with privileged activities.

Right, we fall back on GET when no POSTDATA was saved, which never happens per default (browser.sessionstore.postdata defaults to 0) and shouldn't happen on SSL secured pages, at all (unless browser.sessionstore.privacy_level is changed to 0). So: (In reply to comment #0) > - page contents restored from cache if present, OR This should actually happen. If not, please file a new bug. > interstitial resubmit warning prior to POST being resubmitted, OR That should happen with the prefs mentioned above changed. > message saying that the page isn't available because resubmitting would hurt Isn't this the same as the previous point (just with bug 160144 or similar fixed). At this point we should rather have a "this page can't be displayed due to lack of data" error page (goot luck with late-l10n, though). Alternatively we could just replace all URLs which would require POSTDATA but won't get it due to the mentioned preferences with a different URL of your choice (e.g. a mozilla.org page explaining the issue) - perferrably after having made sure that the page isn't available from the cache, either.

Cached results are not showing, as can be seen by submitting a change (like a comment) on this bug and then restarting your browser. You'll see the "apparently you didn't choose any bugs to modify" page. Maybe that's a Bugzilla strangeness, though? This isn't a regression from Fx2, and doesn't block. I'm also not actually sure that there's a bug here. We *seem* to be doing the right thing by default, except for the "restore from cache" bit.

I don't think we're doing the right thing: on restore we're sending a GET request, when no such GET request was ever made by the user. We're just making up web traffic! If the parameters around when we restore or what we restore haven't changed since 2, then I agree that it shouldn't block.