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

RESOLVED DUPLICATE of bug 195746

Status

--
major
RESOLVED DUPLICATE of bug 195746
16 years ago
5 years ago

People

(Reporter: richard, Assigned: saari)

Tracking

({qawanted})

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

16 years ago
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.
(Reporter)

Comment 1

16 years ago
Forgot to mention that I also experienced this bug in Chimera 0.6.
(Reporter)

Comment 2

16 years ago
Created attachment 117689 [details]
Screen capture of the bug in action.
(Reporter)

Comment 3

16 years ago
Created attachment 117696 [details]
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."

Updated

16 years ago
Whiteboard: DUP

Updated

16 years ago
Keywords: qawanted
Whiteboard: DUP → DUPEME

Comment 4

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

Comment 5

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

Comment 6

16 years ago
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

16 years ago
Richard, does this also happen using Mozilla?
(Reporter)

Comment 8

16 years ago
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

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

Comment 10

16 years ago
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

16 years ago
Andreas, do *you* have HTTP Pipelining enabled?

Comment 12

16 years ago
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.
(Reporter)

Comment 13

16 years ago
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

16 years ago
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.
(Reporter)

Comment 15

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

Comment 16

16 years ago
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 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 16 years ago
Resolution: --- → DUPLICATE

Updated

5 years ago
Whiteboard: DUPEME
You need to log in before you can comment on or make changes to this bug.