All users were logged out of Bugzilla on October 13th, 2018

[FIX]Not correctly retrieving post data when saving a page or frame generated from a form POST

RESOLVED FIXED in Future

Status

()

P2
critical
RESOLVED FIXED
18 years ago
10 years ago

People

(Reporter: joe, Assigned: bzbarsky)

Tracking

(Blocks: 1 bug, {dataloss, relnote})

Trunk
Future
dataloss, relnote
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite ?

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

18 years ago
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.4.5-1mdk i586; en-US; rv:0.9+)
Gecko/20010604
BuildID:    2001060421

Mozilla does not save the respond to a posted form correctly.
Instead of saving the posted reply, it saves the form.

Reproducible: Always
Steps to Reproduce:
1.go to the referenced form
2.type in a URL in the big text box (say http://www.mozilla.org)
3.push dumplinks
4.The form correct displays the page source
5. Now try saving the output
6. You get the form itself and not the response

Actual Results:  You get the form output

Expected Results:  You should get the dumped page.  You do get that in netscape
(Assignee)

Comment 1

18 years ago
See bug 78740.  Please do _not_ mark this duplicate, but rather leave it open to 
track this issue.

dataloss, since saving a page can save nothing useful for dynamic pages and the 
user is screwed if (s)he forgets to check in another browser window what 
actually got saved.
Assignee: asa → pchen
Severity: normal → major
Status: UNCONFIRMED → NEW
Component: Browser-General → XP Apps
Depends on: 40867
Ever confirmed: true
Keywords: correctness, dataloss
QA Contact: doronr → sairuh
Hardware: PC → All
Summary: Reply from posted form not saved correctly → "Save As" reloads from network
->bill? or, is this a networking issue?
Assignee: pchen → law

Comment 3

18 years ago
nav triage team:

This should retrieve the document from the cache. Reassigning to gagan
Assignee: law → gagan
Component: XP Apps → Networking: Cache

Comment 4

18 years ago
the change required to make this happen (from cache) is still with whoever calls
into networking. You just have to make sure you set the right flag--
LOAD_FROM_CACHE. (for reference-- see the history implements this) Back to you
pchen... 
Assignee: gagan → pchen

Comment 5

18 years ago
nav triage team:

Marking nsbeta1+, p2, and mozilla0.9.3
Keywords: nsbeta1+
Priority: -- → P2
Target Milestone: --- → mozilla0.9.3

Comment 6

18 years ago
-> XP Apps.

If you need help w/ testing, let us know. There are probably enough examples in
public URL's for this one.
Component: Networking: Cache → XP Apps
Keywords: relnote

Updated

18 years ago
Keywords: nsenterprise

Comment 7

18 years ago
nav triage team:

Marking nsBranch
Keywords: nsBranch
(Assignee)

Comment 8

18 years ago
*** Bug 88031 has been marked as a duplicate of this bug. ***

Comment 9

18 years ago
So here:
http://lxr.mozilla.org/seamonkey/source/xpfe/components/xfer/src/nsStreamTransfer.cpp#177

we actually set the LOAD_FROM_CACHE flag, and from simple testing, we appear to
corrrectly load from the cache.

I believe the bug here is that we aren't getting the post data from session
history (in fact, nsStreamTransfer::SelectFileAndTransferLocationSpec() is
getting passed in null for the postData parameter), in effect, when saving, we
get the source for the initial form page (though, I think that it was actually
retrieved from the cache).

Resummarizing to "Not correctly retrieving post data when saving a page
generated from a form POST".

I think this bug is now less severe than originally stated, but I will leave it
up to the triage team to determine the fate of this bug.
Summary: "Save As" reloads from network → Not correctly retrieving post data when saving a page generated from a form POST

Comment 10

18 years ago
nav triage team:

(Yes, it's really nav triage team, not just me ;-) )

Bug not as severe as orignally stated, moving out to mozilla1.0 and removing
nsBranch keyword
Keywords: nsBranch
Target Milestone: mozilla0.9.3 → mozilla1.0

Comment 11

18 years ago
See patch posted to bug 40867
(http://bugzilla.mozilla.org/showattachment.cgi?attach_id=41511) for a fix to
this problem.
(Assignee)

Comment 12

18 years ago
The patch there fixes "save as" but not "save frame as"
Summary: Not correctly retrieving post data when saving a page generated from a form POST → Not correctly retrieving post data when saving a page or frame generated from a form POST
(Assignee)

Comment 13

18 years ago
*** Bug 90836 has been marked as a duplicate of this bug. ***

Updated

17 years ago
Depends on: 90722

Updated

17 years ago
Keywords: nsenterprise → nsenterprise+

Comment 14

17 years ago
marking nsenterprise-.
Keywords: nsenterprise+ → nsenterprise-
spam: over to File Handling. i have not changed the assigned developer [or the
other fields for that matter], so if anyone realizes that a bug should have a
more appropriate owner, go ahead and change it. :)
Component: XP Apps → File Handling

Comment 16

17 years ago
moving to mozilla0.9.9
Target Milestone: mozilla1.0 → mozilla0.9.9

Comment 17

17 years ago
->default owner
Assignee: pchen → law
Target Milestone: mozilla0.9.9 → ---

Comment 18

17 years ago
Boris, any idea where this bug stands with respect to the new save logic?  I
know we're preserving the post data stream but I don't know if that's sufficient
in light of the fix Vidur  mentions that also wants to use some sort of cache key.
(Assignee)

Comment 19

17 years ago
That's not sufficient...  What we really want to be able to do is to pass a
cache key to webbrowserpersist.  The back end code will then want to QI the HTTP
channel to a caching channel and set the cache key on that.  This will do two
things:

1)  Allow us to retrieve the correct document from the cache
2)  Allow us to put up a dialog for the user in cases when the document has
    expired from the cache (instead of silently reposting).

See the code in nsDocShell::DoURILoad that handles this case for history loads.
 Saving should be just like history in this regard, imo.

Comment 20

17 years ago
Thanks, turning this over to Adam.
Assignee: law → adamlock

Updated

17 years ago
Target Milestone: --- → Future

Comment 21

17 years ago
*** Bug 128719 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 22

17 years ago
*** Bug 159382 has been marked as a duplicate of this bug. ***

Comment 23

16 years ago
I have a problem saving frames from a dynamic page (on my intranet, I can't
offer you a url, sorry), which looks like it might be related to this bug, but
I'm not sure.  I *don't* have the problem where the original form is saved
instead of the dynamic page.

The page has two frames.  I can save the whole page, that works fine.  But if I
try "Save Frame As" to just get the one frame, mozilla (1.0) refuses, saying
"The link could not be saved. The web page might have been removed or had its
name changed."

So mozilla appears to be trying to access the frame's url anew, instead of using
the HTML it already downloaded.

The odd thing is that I can view the source of the frame, that also works fine.
 But if I try to save the page from the Frame Source view, then it still fails,
with the same error message.

Should this be filed as a separate bug?

Drew Parsons

Comment 24

16 years ago
There appears to be a bug with Netscape 6/7 Post transactions.  I noticed some
questions about this on a list-serve to which I subscribe, but never paid much
attention to it.

However, a couple of weeks ago I did download Netscape 7 and switched to it from
Net 4.7 as my standard browser.  Yesterday, I started some work on new features
for the NCHA web site, and noticed the problem.

It looks to me like the application server is waiting for the POST to be
completed.  Interestingly, I can simultaneously run the same application query
from IE without problems.  An example that shows this:

http://www.norcalhandball.org/players/players.taf

This is a Tango Application server, but there are apparently similar issues with
Tomcat and perhaps others.

This is a production server, and I have a limited number of connections
available, so while it's okay to hit the server to see the problem, if anyone
wants to use it for debugging, I would rather set you up with a separate URL on
a development machine.
QA Contact: sairuh → petersen

Comment 25

16 years ago
By the definitions on <http://bugzilla.mozilla.org/bug_status.html#severity> and
<http://bugzilla.mozilla.org/enter_bug.cgi?format=guided>, crashing and dataloss
bugs are of critical or possibly higher severity.  Only changing open bugs to
minimize unnecessary spam.  Keywords to trigger this would be crash, topcrash,
topcrash+, zt4newcrash, dataloss.
Severity: major → critical
(Assignee)

Updated

16 years ago
Blocks: 115174, 120809

Comment 26

15 years ago
The OS should be All.

Updated

14 years ago
OS: Linux → All

Comment 27

14 years ago
Mozilla doesn't even warn the user that data are reposted. Even if this bug
(reload avoided) cannot be fixed for the moment, I think that until this bug is
completely fixed, Mozilla should display a warning box, where the user can
cancel the repost. This would be very useful, as duplicates may really be
harmful (on sites that can't detect them).

Comment 28

14 years ago
Note bug 288462.

Updated

14 years ago
Blocks: 288462

Updated

12 years ago
Duplicate of this bug: 317982
(Assignee)

Updated

10 years ago
Blocks: 472895
(Assignee)

Comment 30

10 years ago
OK, the core part of this has been done ever since bug 170722 landed.  All that needs to happen is for our front-end to actually pass the right data into nsIWebBrowserPersist.
No longer blocks: 472895
(Assignee)

Comment 31

10 years ago
Gah.  We seem to have no Toolkit component for contentAreaUtils...  I guess I'll toss this in Firefox for now, though it's a toolkit fix.
Assignee: adamlock → nobody
Component: File Handling → File Handling
Product: Core → Firefox
QA Contact: chrispetersen → file.handling
(Assignee)

Comment 32

10 years ago
Created attachment 362349 [details] [diff] [review]
Fix

Two things going on here.  The first change isn't really needed to fix this bug, but it's weird for the persistence object to take either an nsIWebPageDesciptor or a necko cache key but NOT the currentDescriptor of an nsIWebPageDescriptor.  This caused my first patch attempt to fail...

The second change is just a change to pass in the nsIWebPageDescriptor for the document we're saving into saveURI.

I'm not quite sure how to write a test for this; I did test locally that it fixes the bug for me in terms of actually hitting the cache for POST data.  I'd welcome any testing suggestions.

On a separate note, I really don't like this idea of reposting if the data is not in cache (as we do now).  We should probably add some flags to nsIWebBrowserPersist to allow LOAD_ONLY_FROM_CACHE and have fallback UI (a prompt? something else?) for when the data is not cached.  Alternately, we need to fix our caching, finally; I'll post to m.d.t.network about that.
Assignee: nobody → bzbarsky
Status: NEW → ASSIGNED
Attachment #362349 - Flags: superreview?
Attachment #362349 - Flags: review?(jst)
Attachment #362349 - Flags: review?(gavin.sharp)
(Assignee)

Comment 33

10 years ago
Created attachment 362351 [details] [diff] [review]
Er, with the right comments
Attachment #362349 - Attachment is obsolete: true
Attachment #362349 - Flags: superreview?
Attachment #362349 - Flags: review?(jst)
Attachment #362349 - Flags: review?(gavin.sharp)
Attachment #362351 - Flags: superreview?(jst)
Attachment #362351 - Flags: review?(jst)
Attachment #362351 - Flags: review?(gavin.sharp)
(Assignee)

Updated

10 years ago
Summary: Not correctly retrieving post data when saving a page or frame generated from a form POST → [FIX]Not correctly retrieving post data when saving a page or frame generated from a form POST

Updated

10 years ago
Attachment #362351 - Flags: superreview?(jst)
Attachment #362351 - Flags: superreview+
Attachment #362351 - Flags: review?(jst)
Attachment #362351 - Flags: review+
Comment on attachment 362351 [details] [diff] [review]
Er, with the right comments

+    pageCookie = ifreq.getInterface(Components.interfaces.nsIWebNavigation);

I don't understand where the name "pageCookie" comes from here, but assuming that makes sense here, it's all good :)

r+sr=jst
(Assignee)

Comment 35

10 years ago
Hmm.  That was copy/paste from the view-source code.  Originally probably comes from rpott's mind.  I'm happy to call it cacheKey or something instead.
Attachment #362351 - Flags: review?(gavin.sharp) → review+
Comment on attachment 362351 [details] [diff] [review]
Er, with the right comments

I agree with jst about "cacheKey". I think it would be worth adding a comment explaining that all nsIWebNavigations are also nsIWebPageDescriptors, or an explicit QI.
(In reply to comment #36)
> (From update of attachment 362351 [details] [diff] [review])
> I agree with jst about "cacheKey".

Er, I agree with you that "cacheKey" would be better than "pageCookie", I mean.
(Assignee)

Comment 38

10 years ago
Created attachment 363126 [details] [diff] [review]
Updated to review comments.
Attachment #362351 - Attachment is obsolete: true
(Assignee)

Comment 39

10 years ago
Pushed http://hg.mozilla.org/mozilla-central/rev/31689184423e

Filed bug 479296 on the remaining issue.  This still needs a test (presumably a browser one), right?
Status: ASSIGNED → RESOLVED
Last Resolved: 10 years ago
Flags: in-testsuite?
Resolution: --- → FIXED
(Assignee)

Updated

10 years ago
Depends on: 480318

Comment 40

10 years ago
Bug 188253 is about porting the fix to SeaMonkey, but for a more comprehensive
solution see bug 484616.
Blocks: 188253
You need to log in before you can comment on or make changes to this bug.