198156 - image instead of URL loads when I follow a URL link to an HTML page prior to the first page loading

Status: RESOLVED DUPLICATE of bug 195746

(Camino Graveyard :: General, defect)

Description

[Richard Plotkin]

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030306 Camino/0.7
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030306 Camino/0.7

From the versiontracker.com home page, I follow a link before the home page is
fully loaded.  When I do this, I wind up with a URL for a page that displays a
GIF image instead of the page.  I have posted a PDF screen capture of this
phenomenon at http://www.richardplotkin.com/CaminoBug.pdf .  Here, a highlighted
image that says "Windows" appears as the "content" of the page.  When the page
started to load, I clicked on a different image that was a tab saying "Mac OS."
 One further problem is that once this happens, you can't hit the back button,
wait for the page to load, and follow the link again.  It seems that the image
is cached as the original page, and force-reloading will not resolve the page,
nor will opening a new window and typing in the URL, or any other method (only
restarting the browser application will allow you to follow the link correctly).
 The image tends to come from the originating page, and not the URL you wanted
to be at, I think.

Reproducible: Always

Steps to Reproduce:
1.Go to versiontracker.com
2.Before page completely loads, click on one of the tabs at the top of the
versiontracker page.
Actual Results:  
The name of the linked page appeared in the URL field and title, followed by a
description of a GIF image (+ size), and a single GIF image appeared in the
requested window.

Expected Results:  
Should have loaded the HTML data for the requested URL.

Comment 1

[Richard Plotkin]

Forgot to mention that I also experienced this bug in Chimera 0.6.

Comment 2

[Richard Plotkin]

Attachment: Screen capture of the bug in action.

Comment 3

[Richard Plotkin]

Attachment: Screen Capture with Camino Error Message

Here's a different error I get, having to do with the same bug.  Upon pressing
"reload," it tells me "The image http://www.versiontracker.com/macos/" cannot
be displayed, because it contains errors."

Comment 4

[Greg K.]

Richard, if you have HTTP Pipelining enabled, this is a dup of bug 195746.

Comment 5

[Mark Knopper]

I get this bug also without pipelining turned on (with today's unmodified
nightly build).

Comment 6

[Richard Plotkin]

Nope, HTTP pipelining is turned off. So this isn't a dupe of bug 195746. 
Additionally, this one _always_ looks like 195746's "Page Load #1" image, and
_never_ looks like 195746's "Page Re-Load #3" image.  I've noticed that this
tends to be a problem on folder pages w/o a trailing backslash, as well.  E.g.
www.mypage.com/page   would be a problem, but www.mypage.com/page/   would not.

Comment 7

[Greg K.]

Richard, does this also happen using Mozilla?

Comment 8

[Richard Plotkin]

I cannot get the problem to occur in Mozilla (although I did crash it trying).
I am using:
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.3) Gecko/20030312

Comment 9

[S Woodside]

Can't reproduce using my recent build. I followed the instructions exactly. Mac
OS X 10.2.4, TIBook/400 256 RAM.

Comment 10

[Andreas Rossbacher]

I can reproduce that with Mozilla 1.3 release. On the google.com page.
Type anything to the search string, hit return, wait for the result coming
up. Klick und "Images" wait the page loading. You can now see the lower part
auf die small g in Google not loading and if you klick on "Advanced Image Search"
it will show the Image, not load the link.
This happens not alwas, seems to depend on how long mozilla is running. Never
had it with a new instance.

Comment 11

[Greg K.]

Andreas, do *you* have HTTP Pipelining enabled?

Comment 12

[Andreas Rossbacher]

I had, I switched it off and will report if it has any effect.
Right now it works, but it did sometiems before with piplining
enabled.

Comment 13

[Richard Plotkin]

Well, this is odd: I changed my user.js file to ENable HTTP Pipelining.  Same
problem.  DISabled it, and now I cannot reproduce the error.  So it's possible,
now, that this is a dup of bug 195746, as noted by Greg Kolanek.  I'm not sure
why the on-off cycling would fix it; perhaps I needed to explicitly disable it
in user.js with a 'false' label, instead of not having an entry for it at all (I
had it enabled a while ago, and then deleted the pref from the user.js file when
I chose to disable it).  Sorry if this turns out to be a dup.

Comment 14

[Greg K.]

Richard, check your prefs.js for a pipelining setting. You may have used a
third-party program such as ChimeraBooster or SpeedChimera to enable it, and
that would edit your prefs.js rather than your user.js.

Comment 15

[Richard Plotkin]

I did use ChimeraBooster a while ago, but I did not find anything in prefs.js
for pipelining.

Comment 16

[Greg K.]

Since ChimeraBooster's sole function is to enable pipelining, resolving dup.
Richard, a current nightly build of Camino with bug 195746's fix should work.

*** This bug has been marked as a duplicate of 195746 ***