Closed Bug 32293 Opened 24 years ago Closed 23 years ago

[PORKJOCKEY] Can not distinguish urls based on their Postdata.

Categories

(Core :: DOM: Navigation, defect, P3)

Product:
Core
Component:
DOM: Navigation
Type:
defect

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla0.9.1

People

(Reporter: preed, Assigned: radha)

References

(
URL
)

Details

(Whiteboard: need testcase) 

From Bugzilla Helper:
User-Agent: Mozilla/4.72 [en] (X11; U; Linux 2.2.14 i686; Nav)
BuildID:    2000031609

If the URL is the same URL, but the content changes, the back button won't
recognize this, and refuses to move you a page back.

Reproducible: Always
Steps to Reproduce:
1. Go to the above URL
2. Fill out the first two pages of forms
3. Click back; nothing will happen; if you click back a number of times, the
first page with a different URL will eventually get displayed

Actual Results:  When back is clicked, Mozilla just sits there until back is
clicked enough to get a page with a separate URL.

Expected Results:  The different pages should display when back is clicked;
works fine with NS 4.72.

This is most commonly seen with CGIs that determine your state, and figure out
what to display from that, instead of from the URL
Confirmed with 2000-03-18-15-M15 on WinNT - to reproduce with the testcase URL, 
you will need an e-mail address associated with a domain registered through NSI, 
but you won't need to submit a domain mod, so it needn't be your own domain.

This is a Session History problem - the back button is just the most immediate
way of going back.

The fundamental problem here seems to be actually saving the state of the
previous versions of a given URL, and then displaying it when appropriate.
This will include both the page itself and entries into form fields, some of
which may be named the same but contain different data earlier in the session.

The session history is not working correctly when the same URL shows up more 
than once, in a much simpler case - see bug 27829, "history "go" is funky when 
the url's are the same", ASSIGNED, M15. This problem may be related to that as 
well.

This is *not* similar to bug 21611, bug 28758, or bug 29603, despite showing 
the same symptom when clicking on the [Back] button: in those cases the same 
page should not have appeared multiple times in a row in the session history.
Assignee: trudelle → radha
Status: UNCONFIRMED → NEW
Component: XP Toolkit/Widgets → History
Ever confirmed: true
Keywords: 4xp
OS: Linux → All
QA Contact: jrgm → claudius
Hardware: PC → All
Summary: Back button fails on same URLs → Back button fails on same URLs {Session History, forms}
Status: NEW → ASSIGNED
Target Milestone: M15
Move to M16 for now ...
Target Milestone: M15 → M16
Is this still reproducible?
bug 27829 which is related no longer is (reproducible) but this requires more testing...

I tested this with the latest nightly build (2000042809), and it was not fixed.
What happened when I clicked back was instaed of going "back" and just sitting
there not refreshing, as the earlier builds show, mozilla would just go straight
back to the page with the last unique URL. This is still incorrect behavior as
they should go back to the last unique page with the same URL.

I will look at the next few nightly builds to see if this is still the case.
Keywords: nsbeta2
Putting on [nsbeta2+] radar for beta2 fix. claudius, please retest with lastest 
build.
Whiteboard: [nsbeta2+]
Oooh very bad. just like the 4/28 comments. When you click back it just skips the page altogether
and that info it just lost.  Bumping up the severity as this will wreak havoc with forms and the like.
tested with 2000051210 bits
Severity: normal → major
note to qa: anothe page to test this with - http://www.ovid.com/demo signup is free.

Move to M18.
Target Milestone: M16 → M18
*** Bug 40079 has been marked as a duplicate of this bug. ***
40079 has a few comments that may want to be noted, but this seems like a clear
cut bug.

I'll be leaving my test page (http://eliot.landrum.cx/mozilla/test-40079.php) up
until this one (32293) has been resolved. It is a simple PHP script that I wrote
specifically for 40079. It sends no information to anyone and illustrates this
problem well.
I tried the page suggested by Eliot Lantrum. The problem there is,  the 
form posts to itself. Docshell/SH is not able to distinguish between 2 urls that 
differ only in their postdata and nothing  else. This is a known problem. Not 
sure if that is the case in other urls suggested, NSI and ovid pages. Please 
update me on this.
Summary: Back button fails on same URLs {Session History, forms} → Can not distinguish urls based on their Postdata.
Radha, yes, your comments re: my test page are correct. Bug 40079 reported this
problem regarding Mozilla handling back/forward badly with forms posting to
themselves. I don't remember exactly why I marked it as a duplicate of this one,
but claudius@netscape.com's comments were exactly what 40079 was about. My mind
is a bit hazy at the moment...
don, as per our discussion.
Assignee: radha → don
Status: ASSIGNED → NEW
Summary: Can not distinguish urls based on their Postdata. → [PORKJOCKEY] Can not distinguish urls based on their Postdata.
Removing "nsbeta2+" for reconsideration by pdt.

Here's the scoop.  First, there's just no way this is gonna get fixed by beta2.
 Second, this is some big architectural plumbing stuff really isn't all Radha's
responsibility to fix.
Whiteboard: [nsbeta2+]
Putting on [nsbeta2-] radar. Not critical to beta2.
Whiteboard: [nsbeta2-]
over to pollmann.  Eric, ask radha for help to get started,
she says this needs layout/necko work.
Assignee: don → pollmann
From an email I sent earlier:

> However, when I then click "Back", SH compares the current URL with the one we 
> are trying to go back to [nsSHistory::CompareSHEntry()].  These two URLs are
> the same, so we don't go back as we should.

Should this fix to compare post data happen in nsSHistory::CompareSHEntry?  
CC'ing Radha as she is the guru in this area.  :)

eric, I think the comparison s'd happen in 
2 places 

#1)Probably in nsDocShell::ShouldAddToSessionHistory(). In this method, docshell 
will have access to 
a)The previous uri in mCurrentUri, 
b) The uri to be loaded in the argument for ShouldAddToSessionHistory
c) The postdata for the url to be added (can be obtained from nsIChannel if 
nsIChannel is passed to ShouldAddToSessionHistory)

The previous url's postdata is something that won't be available. We need to 
figure a way to get access to it. (May be a member in nsDocShell).

Even if we got hold of the 2 postdata, I'm not sure how we will compare them 
these are curently streams and postdata could be string or file or binary data. 
Layout gurus have to figure this. 
(As a side note, ShouldAddToSessionHistory used to call nsIURI::Equals to figure 
if 2 urls are the same. I thought comparing 2 postdatas can happen there too. 
But rpotts has changed it on 7/6 to not use nsIURI::Equals() and instead checks 
for only "about:blank". You need to talk to him why he removed the 
nsiURI::Equals(). )

#2) I think nsSHistory::CompareShentry() should also do this once we have 
figured how to compare postdata.
Nominating for nsbeta3.
Status: NEW → ASSIGNED
Keywords: correctness, nsbeta3
Marking nsbeta3+. 
Reassigning to Waqar
Assignee: pollmann → waqar
Status: ASSIGNED → NEW
Whiteboard: [nsbeta2-] → [nsbeta2-][nsbeta3+]
Eric, I'm reassigning this back to you. Waqar never had a chance to look at it 
and now he is overloaded with nsbeta3+ bugs.
Assignee: waqar → pollmann
Marking nsbeta3-. There just not enough time to fix this before beta3.
Whiteboard: [nsbeta2-][nsbeta3+] → [nsbeta2-][nsbeta3-]
nav triage team: important to fix for next release. also 55055 depends on this.
Keywords: nsbeta1
Blocks: 55055
cc to self
> Even if we got hold of the 2 postdata, I'm not sure how we will compare them 
> these are curently streams and postdata could be string or file or binary
> data.
Do we have to store the actual postdata? Can we just store the date-time that 
they were posted? That's unique to the millisecond.
Target Milestone: M18 → mozilla0.9
Setting milestone to mozilla0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
claudius@netscape.com, is this still a problem? could this be checked?
Keywords: nsbeta2, nsbeta3 → mozilla1.0
Whiteboard: [nsbeta2-][nsbeta3-]
This bug has gotten a little murky for me and I'm not sure how/what to test. Is it just the issue
from bug 40079 (form posting to itself) or is the problem still more general? If someone, anyone
can point to a current example of the problem I can rework a minimized permanent test and try it
out but for right now I'm stuck.
Whiteboard: need testcase
I've created the following test script, based upon what *I* do when I'm
developing web apps sometimes:

http://www.sigkill.com/cgi-bin/cgiwrap/~preed/mozbug.pl

Moz *used* to fail, although back/forward is seemingly working ok with
2001021503 (Moz 0.8); the only thing Moz does which NS 4.x doesn't is it prompts
the user to resubmit the post data, which sounds like it should be ok.

It *looks* like it's been fixed, but I would try and test on the network
solutions URL above or some other 'real' web app that's in production (which I
would, but I don't have time to do that right just now).
to test at the referenced url for this bug one needs to a Network solutions account.
(I have one but I'll have to go dig up all the registration #'s to jump through their hoops.)

preed: it is probably working now because SH does not use the *URL only* anymore 
to distinguish between pages. But I don't believe there is any mechanism to 
actually distinguish urls based on postdata. Gordon was talking about 
implementing this as part of the new cache.  cc'ing him if this is still true.
Yes, Darin and I worked out the precise mechanism yesterday afternoon. It will 
only require history to hold on to a cacheKey object (an opaque nsISupports) that 
will be about the same size as the URL.  You could keep these only for POST 
requests to save space, and just use the URL for GETs.

By the way, this looks similar to bug 20843.  We are planning on fixing that bug 
in 0.9 (though not in the way suggested by Scott Furman), but I think the summary 
of this bug is a more accurate description of the problem.

cc'ing darin.

Radha, can you take this one?  Thanks!
Assignee: pollmann → radha
*** Bug 68797 has been marked as a duplicate of this bug. ***
This bug seems to be half-fixed: the 'back' button work for me as it should, BUT
please don't forget about the 'view source' feature, which doesn't use the
postdata at all- but only the url as it looks in the location bar.
(testcase: http://www.deot.net/mozbug2.php)
Please don't mutate the original  bug. If the original problem reported by this 
bug is fixed, let's mark it fixed and create a new bug for the view source 
problem.
Well, according to the bug's summary the view source thingie belongs to here,
but ok, I'll file a new bug.
The original problem described here is fixed. Please open a new bug for any 
view-source problem.
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
Good,
the view-source bug is already opened, bug 64100 .
mass-verifying claudius' Fixed bugs which haven't changed since 2001.12.31.

if you think this particular bug is not fixed, please make sure of the following
before reopening:

a. retest with a *recent* trunk build.
b. query bugzilla to see if there's an existing, open bug (new, reopened,
assigned) that covers your issue.
c. if this does need to be reopened, make sure there are specific steps to
reproduce (unless already provided and up-to-date).

thanks!

[set your search string in mail to "AmbassadorKoshNaranek" to filter out these
messages.]
Status: RESOLVED → VERIFIED
Component: History: Session → Document Navigation
QA Contact: claudius → docshell
You need to log in before you can comment on or make changes to this bug.