227554 - [FIX]history back does not reflect the change (page source code does not tally what is displayed)

Status: RESOLVED FIXED

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

Description

[Marc Rechté]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.5) Gecko/20031007
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; fr-FR; rv:1.5) Gecko/20031007

Hi,

I think I discovered a bug that has been in Mozilla since its early version and
that is platform independant.

This problem happens on the following versions: 1.5 on WinXP, 1.3 on Win98SE,
1.0.1 on Linux RH8.

A page has php code that generate the following code body

<p>There is an error...
<BR><BR>
<FORM>
  <INPUT TYPE="button" value="OK" onclick="window.history.back()">
</FORM>


When the user presses the OK button, Mozilla does not show the previous page,
but if one dispalys the page source code, it is reflecting the previous page !

If the user presses again the OK button, then he/she returns to the *previous
previous page*.

This problems appears in only *one place* of our Web site, altgough we use that
kind of constructions in many places.

Note that Netscape 4.75 (and MS Internet Explorer) has no problem with this page.

If you are interested I can explain you how to reproduce the problem on our
French Web site, it is quite simple.

Regards,
Marc Rechté.

Reproducible: Always

Steps to Reproduce:
1. Register a new user (right part of the form)
2. Choose form the menu "Enregistrer une nouvelle demande de logement"
3. On the last field of the form (Code postal) enter: 99999, then click  on the
button.
4. You get an error message. If you try to navigate back (or press the OK
button), nothing changes

Actual Results:  
Nothing !
Try to display the page source code: it does not tally the display !

Expected Results:  
Display the previous page

Comment 1

[Boris Zbarsky [:bzbarsky]]

> http://www.sodineuf.fr/idtutl.php3

When I load this it claims that I have cookies disabled (which is false, though
I do have them enabled for the originating site only).

Comment 2

[Hermann Schwab]

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.6b) Gecko/20031205
Tinderbox Build 2003-12-05-10h51

I´m getting the same error message, but there is something wrong with my cookie
preferences.
before testing, I checked that cookies are unblocked for ALL, session only,
images allowed for ALL, and popups unblocked.
After getting the cookie error message, I closed the tab, checked tools->cookie
manager settings, and changed them from 'Use default' to 'Allow Cookies for this
Site'. Then I rechecked my cookie settings in preferences, and noticed 2nd time,
that the only thing checked was the Enable ALL checkbox, all other settings on
this page were lost.
Cookiemanager was showing www.sodineuf.fr allowed, but loading the page produced
same error message.
I´ll retest with older builds.

Comment 3

[Marc Rechté]

I am very sorry, I forgot that a cookie is set on the main page of the site.
Before going to the mentionned page go first to www.sodineuf.fr and wait the
page is fully loaded before going to idtutl.php3 ("Demande de Logement" tab).

Comment 4

[Boris Zbarsky [:bzbarsky]]

I've registered the user "mozilla", password "mozilla".  Now the left hand side
of the form can be used with those values in step 1; the other steps are as in
comment 0.

The problem is that the the same PHP script handles both the first and second
page, looks like.... and that the two differ by just an anchor.  When history
does the load, that goes through nsDocShell::LoadURI, which notices that the two
URIs are identical and just scrolls.

Somehow we need to detect that the documents corresponing to the two history
entries are actually different.  Maybe the ScrollIfAnchor call InternalLoad()
should only happen if aSHEntry is null or aSHEntry's postdata is the same as
mOSHE's postdata?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Attachment: Somewhat like this

This incidentally fixes a bug we had where if you loaded a page via POST and
then clicked on a named anchor on that page and then hit "back" we would
actually reload the page instead of just scrolling the view...

Comment 6

[Boris Zbarsky [:bzbarsky]]

Comment on attachment 136922 [details] [diff] [review]
Somewhat like this

Adam, Darin, what do you think?

Comment 7

[Boris Zbarsky [:bzbarsky]]

Taking.

Comment 8

[Adam Lock]

I don't know if XPCOM likes interface pointer comparison but the approach seems
reasonable otherwise.

Comment 9

[Boris Zbarsky [:bzbarsky]]

We want to detect the case when we manually copied the postdata stream between
SHEntries when scrolling a page, so we can in fact just do strict pointer
equality comparison...

Comment 10

[Boris Zbarsky [:bzbarsky]]

Adam?  Darin?  Reviews?  I'd like to get this into alpha so it gets maximum
testing time...

Comment 11

[Adam Lock]

Comment on attachment 136922 [details] [diff] [review]
Somewhat like this

r=adamlock

Comment 12

[Darin Fisher]

Comment on attachment 136922 [details] [diff] [review]
Somewhat like this

sr=darin

Comment 13

[Darin Fisher]

>I don't know if XPCOM likes interface pointer comparison but the approach seems
>reasonable otherwise.

interface pointer comparisons are fine.. they are just like normal object
comparisons, provided both interface pointers are of the same type.

Comment 14

[Boris Zbarsky [:bzbarsky]]

> provided both interface pointers are of the same type.

Not quite true when tearoffs are involved.....

Comment 15

[Boris Zbarsky [:bzbarsky]]

Checked in for 1.7a.