Closed
Bug 198156
Opened 21 years ago
Closed 21 years ago
image instead of URL loads when I follow a URL link to an HTML page prior to the first page loading
Categories
(Camino Graveyard :: General, defect)
Tracking
(Not tracked)
RESOLVED
DUPLICATE
of bug 195746
People
(Reporter: richard, Assigned: saari)
References
()
Details
(Keywords: qawanted)
Attachments
(2 files)
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•21 years ago
|
||
Forgot to mention that I also experienced this bug in Chimera 0.6.
Reporter | ||
Comment 2•21 years ago
|
||
Reporter | ||
Comment 3•21 years ago
|
||
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."
Richard, if you have HTTP Pipelining enabled, this is a dup of bug 195746.
Comment 5•21 years ago
|
||
I get this bug also without pipelining turned on (with today's unmodified nightly build).
Reporter | ||
Comment 6•21 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.
Reporter | ||
Comment 8•21 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•21 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•21 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•21 years ago
|
||
Andreas, do *you* have HTTP Pipelining enabled?
Comment 12•21 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•21 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•21 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•21 years ago
|
||
I did use ChimeraBooster a while ago, but I did not find anything in prefs.js for pipelining.
Comment 16•21 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
Closed: 21 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•