Saving POST result page silently resends POST data if page no longer in cache
Categories
(Firefox :: File Handling, defect, P3)
Tracking
()
People
(Reporter: bzbarsky, Unassigned)
References
(Depends on 1 open bug)
Details
(Keywords: uiwanted)
Attachments
(1 file)
76.71 KB,
image/png
|
Details |
Reporter | ||
Comment 2•16 years ago
|
||
Comment 3•16 years ago
|
||
Reporter | ||
Comment 4•16 years ago
|
||
Comment 5•16 years ago
|
||
Comment 7•16 years ago
|
||
Comment 8•16 years ago
|
||
Comment 9•15 years ago
|
||
Comment 10•3 years ago
|
||
@Boris, is this issue still reproducible or it can be closed since there are no new updates for a long time?
Thanks!
Comment 11•3 years ago
|
||
There are steps in comment 0 that could be used to check if this issue still applies or not.
Comment 12•3 years ago
|
||
I tested this issue using the steps from comment 0. Can you please confirm that silent repost refers to the post that appears after Saving page as HTML? I attached a screenshot with my results after saving page as HTML and no other actions on the page.
Comment 13•3 years ago
|
||
Updated•3 years ago
|
Reporter | ||
Comment 14•3 years ago
|
||
It's hard to say what's going on there, especially given the serviceworker. But also, as far as I know the fetches "save as" does don't show up in the devtools network panel anyway.
I just tried those steps with https://www.randomresult.com/num.php and I definitely see a new POST happening when I save, in that the saved data does not match the displayed data, if I clear cache before saving.
I believe I also see a new POST happening on "view source" (again, based on examination of the actual data in the source and whether it matches the original page), which is really broken. I tested with "view_source.tab" both true and false and see the same behavior in both cases.
Updated•3 years ago
|
Comment 15•3 years ago
|
||
(In reply to Boris Zbarsky [:bzbarsky] from comment #14)
It's hard to say what's going on there, especially given the serviceworker. But also, as far as I know the fetches "save as" does don't show up in the devtools network panel anyway.
They do show up in the browser toolbox's network panel. :-)
I just tried those steps with https://www.randomresult.com/num.php and I definitely see a new POST happening when I save, in that the saved data does not match the displayed data, if I clear cache before saving.
Yeah, same. This still seems broken.
I believe I also see a new POST happening on "view source" (again, based on examination of the actual data in the source and whether it matches the original page), which is really broken. I tested with "view_source.tab" both true and false and see the same behavior in both cases.
I filed bug 1721580 for the view source case.
In terms of what to do here, I think a warning along the same lines as the history navigation case would make sense. The docshell code for the history navigation case is here:
and the relevant prompt is completely encapsulated in a simple idl API call that we can easily reuse
However, it is not clear to me how the webbrowserpersist code (which sets up the channel to make the request for the "HTML only" save) would know whether or not there'd be a cache hit for the request. Nihanth, do you know?
Updated•3 years ago
|
Comment 16•3 years ago
|
||
Whoops, meant to look at this earlier and then it got lost in backlog when I went on vacation.
I think we have an opportunity to do some logic in nsWebBrowserPersist::SaveURIInternal, which seems to do the actual loads for each URI. There are some load flags being set (defaults). I wonder if we could try to do a cache-only load, and if it fails, prompt before doing a network load?
I didn't dig further than that because I couldn't reproduce - clearing all data and then saving the page didn't show an extra POST request nor did I see newly generated random numbers in the saved page. Any chance something "fixed" this already in the 2 months that I didn't respond here, I wonder? I can ask in the necko meeting tomorrow...
Reporter | ||
Comment 17•3 years ago
|
||
clearing all data and then saving the page didn't show an extra POST request
Just to double-check: did you save as "Web Page, HTML only", or "Web Page, complete"? The default behavior in a clean profile is "Web Page, complete", iirc. The codepath that has the bug is "Web Page, HTML only".
Comment 18•3 years ago
|
||
You're right, I missed that somehow. I can reproduce with https://www.randomresult.com/num.php.
I think my suspicion in comment 16 that this might be actionable still holds, but my queue is pretty full right now so I'll have to let this go through triage.
Updated•3 years ago
|
Description
•