Closed Bug 85923 Opened 23 years ago Closed 23 years ago

Following a link and then clicking back displays a blank page

Categories

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

x86
All
defect

Tracking

()

VERIFIED FIXED
mozilla0.9.2

People

(Reporter: sean.schneyer, Assigned: darin.moz)

References

()

Details

(Whiteboard: [PDT+] critical for 0.9.2; ready for checkin)

Attachments

(1 file)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Win 9x 4.90; en-US; rv:0.9.1+) Gecko/20010613
BuildID:    2001061304

If I do a google search such as: http://www.google.com/search?q=hacked+802.11
and follow a link then click back the page is blank

Reproducible: Always
Steps to Reproduce:
1. Go to http://www.google.com/search?q=hacked+802.11
2. Follow the first link to the Slashdot article
3. Click the Back button (also works if you use the Right Mouse Button -> Back
sequence)


Actual Results:  The page was blank.

Expected Results:  The page should have contained the previously loaded search
results.
Confirming on Linux, 2001061408.  The url is correctly set back to the google
query, but the page is a uniform field of relaxing grey.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows ME → All
I also see this on win32, linux and mac.

OK, here's what I've discovered:

1. launch browser and visit http://www.google.com
2. do a query for "asa"
3. do a view source on the results of that query

The view source is empty.  Now go to one of the results (what this bug is really
about) of that search and then hit the back button and the page is empty.

A reload of the page brings the results back. I have no idea if my view-source
observation is related. A wild guess is that we are caching an empty page and 
then going back to the cached page when we hit the back button.  This seems to
support my other wild guess that we are viewing source against the cached (empty
html doc) copy of the site.  I did a little test and set cache to Never and
sizes to 0 and the back button refetched from the network and the page displayed
fine.  Based on all these guesses I'm sending this to Networking: Cache.  

also (another guess) is it possible that the page is telling us not to cache the
results and instead of not caching we're caching an empty html document?  
Assignee: asa → gordon
Component: Browser-General → Networking: Cache
QA Contact: doronr → tever
Okay, I tried testing your theory. So, I cleared my cache, opened up the
NewCache folder. I then loaded http://www.google.com/search?q=asa and took a
look at what got created.

There was a 15K file that did, in fact, contain the actual source for the search
results. I then clicked on View Source and got the blank page, but the 15K
cached page was still there, so it wasn't trying to access the blank page from
the NewCache folder.

It did sound like a compelling theory though!
This sounds more like a view-source or session history problem.  It may be a dup.
Assignee: gordon → radha
Component: Networking: Cache → History: Session
QA Contact: tever → claudius
I also ran into this problem and could consistently reproduce it with build
2001061304.  When I tried the same test using the 0.9.1 milestone build
(2001060703) I could not reproduce the problem.  So it appears this problem was
introduced somewhere between those two builds.
*** Bug 86026 has been marked as a duplicate of this bug. ***
*** Bug 86002 has been marked as a duplicate of this bug. ***
*** Bug 86083 has been marked as a duplicate of this bug. ***
Still seeing this on 2001061504 with WinME
*** Bug 86347 has been marked as a duplicate of this bug. ***
This bug is gonna be mostfreq if not fixed for next release.
*** Bug 86471 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
Priority: -- → P2
Target Milestone: --- → mozilla0.9.3
Whiteboard: critical for 0.9.2
it would be good if we can get this moved back into 0.9.2 and get if fixed in
the next couple of days if possible.
I did a bit of debugging and the reason that nothing is showing up is because
when the entry is pulled out of the cache, the 'Content-Encoding' header has
been set to 'gzip' ...  

so we install a gzip content decoder - which fails because the content is *not*
gzip.  This causes the parser to not receive an OnDataAvailable - so it
'creates' an empty document...

I'm going to debug a bit more to understand why the Content-Encoding has been
set to gzip in the first place...
Long shot, but it *might* have something to do with Mozilla wanting to display
gzipped files, rather than download them, recently (fixed now (?)).  More
likely, that was just a server misconfig, but you never know...
Ok... 

It appears that google is sending the response back with a Content-Encoding:
gzip header.  This header gets cached along with the rest of the response
headers in the cache entry.  Unfortunately, when we tee the data off into the
cache it has *already* been unzipped!  

So, when we retrieve it from the cache (when the BACK button is pressed) we try
to unzip the data stream *again*...  Of course this fails and we display an
empty document.

I believe that we need to make sure that the Content-Encoding header is cleared
in the cache entry - since the data has already been decoded.
-> me
Assignee: radha → darin
Status: ASSIGNED → NEW
Target Milestone: mozilla0.9.3 → mozilla0.9.2
Are you *certain* that google is sending back a 'Content-Encoding: gzip' header?

I just pulled some raw headers from google.com using a comand-line tool, and I
saw no such headers.

I have observed this same symptom on many pages besides google, including my own
server, which is CERTAINLY not sending gzip encoding

This seems to be happening anywhere there is a "get" style query line, such as
the '?q=whatever-you-searched-for' in the url of google searches

sr=rpotts.
*** Bug 86970 has been marked as a duplicate of this bug. ***
r=gordon
MozillaUser@HamsterRepublic.com, on what other pages have you seen this? I would love
another testcase. I've tried with Netscape, Alatavista, and Hotbot searches and have been
unable to repro. _Every_ single dupe cited here references google and only google.
http://sourceforge.net is another example.
Whiteboard: critical for 0.9.2 → [PDT+]
Whiteboard: [PDT+] → [PDT+] critical for 0.9.2
I saw this today on excite.com , when using build 2001062004 on Windows 95, but
when I tried it at home tonight on Windows 98 (same build) I couldnt reproduce
it there. *shrug*

The other site it was happening on was an in-house web-app I was developing on
my own Apache server. I cant post a link to that, since its on a host
non-routable ip.

Ill post if I find any other testcases.
a=blizzard on behalf of drivers for 0.9.2
Whiteboard: [PDT+] critical for 0.9.2 → [PDT+] critical for 0.9.2; ready for checkin
fix checked in
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
*** Bug 86810 has been marked as a duplicate of this bug. ***
*** Bug 87078 has been marked as a duplicate of this bug. ***
*** Bug 87155 has been marked as a duplicate of this bug. ***
woo-hoo! google testcase works for me now on 062104 mozilla win32 build on win2K.
It works for me as well on 2001062204 build on Windows ME.
VERIFIED Fixed with 20010621 builds on all platforms
Status: RESOLVED → VERIFIED
*** Bug 87648 has been marked as a duplicate of this bug. ***
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.

Attachment

General

Creator:
Created:
Updated:
Size: