Closed Bug 300032 Opened 20 years ago Closed 16 years ago

Text Web page generated by POST is retried as GET when Save As or Send Page used

Categories

(Core Graveyard :: File Handling, defect)

defect
Not set
major

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: andrew, Assigned: Paolo)

References

()

Details

User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.8) Gecko/20050511 If an HTML form generates a page with content-type text/plain using HTTP POST, it can be printed correctly. However, if the page is saved to a file or sent as an email attachment, the page is re-requested using HTTP GET with no arguments. Typically this results in a blank form Reproducible: Always Steps to Reproduce: 1.Submit a form using HTTP POST (in the test URL, POST, Display Text) 2.Save page 3. Actual Results: The saved page is missing the information posted in the form Expected Results: The saved page would be identical to the screen contents, and would not generate a second HTTP POST operation. If the page was cacheable, was cached and not expired, the cached copy could be used. The browser sends an HTTP HEAD request before the GET request. If the page is cacheable, the saved page is stale (it has an earlier date than that on the screen) Firefox 1.0.4 behaves the same for text/plain as for text/html, i.e. it does a second POST operation and the saved file is "correct", in that it has the correct form fields. However this is also a bug (submitted separately)
Assignee: general → file-handling
Component: General → File Handling
Product: Mozilla Application Suite → Core
QA Contact: general → ian
Version: unspecified → 1.7 Branch
So we have a problem here. First of all, we have the following code in contentAreaUtils.js: postData : isDocument ? getPostData() : null, Unfortunately, earlier on we do: var isDocument = aDocument != null && saveMode != SAVEMODE_FILEONLY; which means that for text/plain content isDocument is false (because saveMode is in fact SAVEMODE_FILEONLY). Even if we fix that first check to look at aDocument instead of isDocument, we still break for subframes, because we always get the post data for the latest toplevel session history entry, which is not really what we want when subframes are involved. Now we _could_ sorta cheat here by getting the docshell from the document, getting the web page descriptor, QIing to nsISHEntry, and getting the post data off of that. That relies on lots of undocumented stuff, however, and might still not work depending on what we do with postdata when we clone session history trees... Thoughts on how to fix this in a sane way?
Severity: normal → major
Flags: blocking1.9a1?
Version: 1.7 Branch → Trunk
Flags: blocking1.9a1? → blocking1.9-
Whiteboard: [wanted-1.9]
Status: UNCONFIRMED → NEW
Ever confirmed: true
My site serves a lot of tabular data in plain text format, so that users can save it easily using 'Save Page As ...'. Bug 300032 kills this functionality on Firefox (it works great with every other browser, including Mozilla). Is there a work around for the developer to restore this functionality?
Flags: wanted1.9+
Whiteboard: [wanted-1.9]
(In reply to comment #1) > Even if we fix that first check to look at aDocument instead of isDocument, we > still break for subframes, because we always get the post data for the latest > toplevel session history entry, which is not really what we want when subframes > are involved. > > Now we _could_ sorta cheat here by getting the docshell from the document, > getting the web page descriptor, QIing to nsISHEntry, and getting the post data > off of that. Bug 471962 covers that, it looks like, and bug 84106 fixed this in the common case where we have the page cached, I think. I guess we can morph this into fixing the isDocument check to not care about saveMode?
Assignee: file-handling → nobody
OS: Linux → All
QA Contact: ian → file-handling
Hardware: x86 → All
This bug is basically bug 471962. I'd say dup one way or the other and fix the postdata-getting in a single bug.
Depends on: 471962
As Boris already noted on bug 471962, this is more related to bug 471875. I'll provide a fix for this issue as part of my work there.
Now that bug 471962 is fixed, the remaining fix here is quite simple. Just replace the line... postData : isDocument ? getPostData(aDocument) : null, ...with a check for aDocument only: postData : aDocument ? getPostData(aDocument) : null, This fix is now also included in the latest patch attached to bug 471875.
Depends on: 471875
Fixed by checkin for bug 471875. Could use a regression test....
Assignee: nobody → paolo.02.prg
Status: NEW → RESOLVED
Closed: 16 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.