Closed Bug 98890 Opened 23 years ago Closed 22 years ago

The URL of the image is showed instead of the image

Categories

(Core :: Graphics: ImageLib, defect, P2)

Product:
Core
Component:
Graphics: ImageLib
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 121084
Milestone:
mozilla1.1beta

People

(Reporter: gfk, Assigned: pavlov)

References

(
URL
)

Details

Attachments

(5 files)

Example of image that didn't load (only see the border)
9.33 KB, image/jpeg
Details
Portsniff of the loading of a broken image by Mozilla
47.84 KB, text/plain
Details
Packet capture from http://www.subpop.com/history/images/1.jpg
189.42 KB, text/plain
Details
Packet capture, in Ethereal's format
22.47 KB, application/octet-stream
Details
Packet capture, short summary
8.12 KB, text/plain
Details 
From Bugzilla Helper:
BuildID:    2001 08 30 08

When I try to load images in this page, Mozilla sometimes shows the URL 
of the image in the document for some images. It should show the image.

Reproducible: Sometimes
Steps to Reproduce:
1. Visit the URL mentionned above.
2. You will see that some image don't appear (you only see their border). 
The images that don't appear are different on each reload.
3. Click on the images.

Actual Results:  For some images, the document body is:
http://www.hitechmods.com/mods/DVD_Win-LED/DVD-MOD-xx.jpg 
(where xx is the number of the image)
Show source shows nothing.

Expected Results:  The image should show in the document body.

If I sniff the port traffic when loading the problematic images, I see that the 
image is actually downloaded by Mozilla.
All the images shows up as expected for me with 2001-09-07-21 on Linux. I tried
reload, shift-reload and it still worked.
Maibe that bug is Mac only.

Here's a better way to reproduce the bug:

Reproducible: Always
Steps to Reproduce:
1. Load the URL above
2. Locate an image that did not load; see 
http://bugzilla.mozilla.org/attachment.cgi?id=48797&action=view for an 
example (circled in red)
3. Ctrl-click on an image that didn't load and choose "Copy Link Address"
4. Paste the URL in the Url box and press enter

Actual Results:  The document body is (in text):
http://www.hitechmods.com/mods/DVD_Win-LED/DVD-MOD-xx.jpg 
(where xx is the number of the image)
Show source shows nothing.

Expected Results:  The image should show in the document body.
I've been able to reproduce with Mozilla Build 2001 09 07 08 on Mac OS 
9.1.2 (same machine as with build 2001083008).
I found something interesting while looking at the port traffic when Mozilla 
is not able to load an image. See the above attachment for the complete 
session.

Mozilla sends a request for the image and the server replies with the 
image. After the image is received, Mozilla sends another request for the 
same image and something breaks:
-----
Send data (635 bytes) on stream 1.
<000001C5< GET /mods/DVD_Win-LED/DVD-MOD-21a.jpg HTTP/1.1  
<000001F5< Host: www.hitechmods.com  
<0000020F< User-Agent: Mozilla/5.0 (Macintosh; U; PPC; en-US; 
rv:0.9.3+) 
<0000024D< Gecko/20010907  
<0000025D< Accept: text/xml, application/xml, application/xhtml+xml, 
<00000297< text/html;q=0.9, image/png, image/jpeg, image/gif;q=0.2, 
<000002D0< text/plain;q=0.8, text/css, */*;q=0.1  
<000002F7< Accept-Language: fr-ca, en-us;q=0.50  
<0000031D< Accept-Encoding: gzip, deflate, compress;q=0.9  
<0000034D< Accept-Charset:   
<0000035F< Keep-Alive: 300  
<00000370< Connection: keep-alive  
<00000388< Referer: 
http://www.hitechmods.com/mods/DVD_Win-LED/DVD-MOD-21a.
<000003C8< jpg  
<000003CD< If-Modified-Since: Fri, 24 Aug 2001 03:20:12 GMT  
<000003FF< If-None-Match: "0be66af4b2cc11:a6c"  
<00000424< Cache-Control: max-age=0  
<0000043E<   

Receive disconnect indication (T_DISCON_IND = 126) on stream 1.
  Reason = 54
  Sequence Number = 0
-----

That would be interesting to know what is this "Reason = 54".
I received an email from a web developper experiencing the same 
problem:
-----
[...]
I am using this version:
Netscape 6.1
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:0.9.2) Gecko/20010726
Netscape6/6.1

.. and having the same frustrating problem you described.  I also had a
report of someone using Netscape 6.1 on a Mac experiencing the 
problem.

Specifically, I experience the problem on a secure site; I have image links
for navigation and Netscape 6.1 sometimes displays the graphics and
sometimes not.  I turned off TLS and it didn't make a difference.  I tried
different themes and had the same result.  I just can't figure out why it's
behaving like this and I hope the problem is with the browser; not my site
(I never saw this behavior with other browsers).
-----
Setting platform/OS to All/All since she reproduced this on Windows. 
Could someone check if this is reproducable on Linux?
Adding Mozilla1.0 keyword and setting priority to P2 since this is a bug 
common to all platforms.
Keywords: mozilla1.0
OS: Mac System 9.x → All
Priority: -- → P2
Hardware: Macintosh → All
I have seen this problem, and can reproduce it consistently using the
photo-images used in Yahoo! profiles. Go to mine:

http://profiles.yahoo.com/rjray_perl

and click on the picture. You will see the URL displayed as text, instead. I
have not sniffed the wire on this to confirm that the image is transmitted in
full, but using the HEAD command from the libwww-perl toolset, I have confirmed
that the picture URL:

http://us.f1.yahoofs.com/users/84888b48/bc/Yahoo!+Photo+Album/small---1.jpg?bcjwKkqBtKNlMwVC

returns "Content-Type: image/jpeg" amongst the headers.

Pasting that URL directly into the location bar also yields the text, rather
than the image.
*** Bug 99992 has been marked as a duplicate of this bug. ***
Target Milestone: --- → Future
Have we made any progress on this at all? If anything, it's been getting worse
for me in the last few weeks. Some images will display fully (or nearly fully)
and only then will Mozilla wipe out the image and show the URL instead. Usually
a shift-reload will make it redisplay and stay displayed. A very annoying problem.

How can this be marked with "Major" severity and "P2" priority - but not have
any work done on it?  There's been no apparent activity here in many months. 
Surely, the severity/priority of the bug warrants more attention than this.
From a dup bug bug 99992

good testcase: http://www.subpop.com/history/images/1.jpg
I cat reproduce the problem as described in comment #12 on linux trunk build
2002022121.
I can reproduce the problem as described in comment #12 on linux trunk build
2002022121.
It seems that with recent builds, this problem became very frequent.
I'm seeing this all over the Amazon.com website in build 2002030511, with the
store icons. For example:

http://g-images.amazon.com/images/G/01/icons/icon-music.gif

Loading this image results in just the text of the URL showing. Hitting
shift-reload makes it load correctly.

Sean: I dont see it on Amazon, but I still see it with JPEG from comment #12 on
Linux build 2002030607-trunk.
Can you try that JPEG in comment #12 and tell whether you see it too?

I'll put it another way:

Does anyone not see this with comment #12? If everyone sees this, then there's
no need for more testcases...
Well....

I do see it with the JPEG in comment #12, but it's different. With that image,
no amount of reload, shift-reload or anything will make the image show up. It's
always the URL text. With the Amazon.com icon, it reliably (for me) shows the
text the first time and reliably shows the actual image after a shift-reload.
I've seen this elsewhere too, but I haven't saved URLs for testing. With larger
images, it seems to load the image and then shortly after the image has loaded
(anywhere from instantly to four seconds later), it flashes away and the URL
text shows instead. A shift-reload makes it load again and stay loaded. The
Amazon.com icon may be doing this as well, but it's loading so fast that I can't
see the initial load. 

I'm not sure if these are caused by the same problem or not, but the behavior is
definitely different.

Also, I'm not sure that I'm seeing the double-GET behavior explained in Comment
#6. At first, I thought I was. In fact, I'm pretty sure I saw it once (an
initial GET and then a second one about 0.2 seconds later). But I quit Mozilla,
completely nuked the cache, started it back up, and went to the URL in Comment
#12. It still just displayed the text, and there was only a single HTTP GET. 

Also, there seems to be something wrong with that image. Barely anything wants
to open it (xv, IE and gimp won't, Navigator 4 will but it looks corrupted). So
I don't think this is an appropriate test case anymore -- it might just be a
corrupted image (I'm pretty sure that wasn't the case when I reported Bug
#99992, but I'm not sure).

I'm really trying to find a better testcase. I know that I've seen this on
images that everything else will open, but I didn't save the URLs because I
thought we had a good testcase here. Hopefully I'll find something soon.

Okay, here's one.  Note, however, that it shows some adult images.  (This may
explain why concrete examples have not been immediately forthcoming.)  Also that
I cannot give a link directly to one of the images (explanation follows).

http://one.mottz.com/BigBro/xxxx/x-mark.html

If you type in the URL that it shows (after it replaces the picture, and which
the main page links to in its HTML) you get a file not found.  The only way to
see the picture is to click on it from the main page then hit Shift-Reload.
Yeah, that site has the problem for me as well (just going to the URL and
clicking on a picture). I don't get any terribly helpful debug messages when
this happens, btw:

Document http://one.mottz.com/BigBro/xxxx/x-mark.html loaded successfully
XXX Damage rectangle (5145,9675,3016,16) does not intersect the widget's view
(0,0,13305,9675)!
XXX Damage rectangle (1650,10965,11581,16) does not intersect the widget's view
(0,0,13530,10965)!
pldhash: for the table at address 0x0x892ca04, the given entrySize of 28
probably favors chaining over double hashing.
Document http://one.mottz.com/BigBro/xxxx/image001.jpg loaded successfully
pldhash: for the table at address 0x0x87f5204, the given entrySize of 28
probably favors chaining over double hashing.
XXX Damage rectangle (10875,10965,1936,16) does not intersect the widget's view
(0,0,13530,10965)!
Document http://one.mottz.com/BigBro/xxxx/image001.jpg loaded successfully


The second time is the shift-reload. Are there any defines or compile flags I
can set to get more information out of the code involved here?

Interestingly, if I copy that image to one of my webservers and load it from
there, it loads fine. So it looks like there must be some difference in how the
server is responding.

Alright, here we go.

In response to the click, Mozilla is sending an HTTP GET with the correct
headers, including Referer. Shortly (practially immediately) after the entire
response of the first GET has been received, Mozilla sends a second HTTP GET for
the same file. However, this second GET does not include a Referer header. Since
the server is strictly enforcing the existence of a correct referer, it's
sending back the 404 page (not actually a 404, but a 302 redirect to /404.html)
in response to the second GET.

Here are the two requests Mozilla sent when I tried to load one of those images:

GET /BigBro/xxxx/image002.jpg HTTP/1.1

Host: one.mottz.com

User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.8+) Gecko/20020223

Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1

Accept-Language: en-us, en;q=0.50

Accept-Encoding: gzip, deflate, compress;q=0.9

Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66

Keep-Alive: 300

Connection: keep-alive

Referer: http://one.mottz.com/BigBro/xxxx/x-mark.html




GET /BigBro/xxxx/image002.jpg HTTP/1.1

Host: one.mottz.com

User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.8+) Gecko/20020223

Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1

Accept-Language: en-us, en;q=0.50

Accept-Encoding: gzip, deflate, compress;q=0.9

Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66

Keep-Alive: 300

Connection: keep-alive

If-Modified-Since: Mon, 04 Mar 2002 13:23:06 GMT

If-None-Match: "3189f7-de7f-3c83753a"

Cache-Control: max-age=0



So I think there are two questions here. First, why is Mozilla requesting the
image twice? And second, why is it not sending a Referer header with the second
request?
 
 
 


So, any additional thoughts on this? Does my diagnosis in Comment #27 not make
sense?

I haven't been able to duplicate this on my own servers, for some reason. I
can't figure out what it is that makes Mozilla request the image twice. It just
doesn't do it on my server, no matter what I do. Even with the same image files.
And it always seems to do it on the server in the example. Examining the headers
that the server sends back, the only ones that are different are the expected
ones (Date, Last-Modified, ETag and Server). All others, are identical. And the
differences aren't unusual (e.g. no strange last-modified dates or anything). 

Also, on a higher level, it seems that the image library should be providing
more useful error messaging than just spitting out the URL string (or whatever
it is that's doing that). As far as I can tell, whenever it has a problem
displaying an image, it just shows the URL. That's pretty confusing to the user.
 A broken image icon or even a generic error message would be nice.

My 2 cents.

If the Images actually where corrupted of some sort, why are they displaying
after shift-reload without an error (or in this case url)?

regards,

Stefano
The images aren't corrupted.  They display before the Shift-Reload (briefly) and
then properly after it.  After it, they can also be downloaded and hosted on
another server without this problem.  The difficulty lies in the method in which
they are being hosted on the orignal servers.  Something is going on that
produces this bizarre behaviour.  Until it can be isolated, there's no way of
knowing if it's a Mozilla bug or not.  (However, other browsers do not do this,
nor did Mozilla up until about 6 months ago - increasingly as time went on.)
While it's possible (likely) that there's someting odd going on with the remote
server, I'm of the opinion that there are definitely a few Mozilla bugs here:

1. I'm not convinced that there's anything that the server should be able to do
to make Mozilla immediately GET the image a second time.

2. If Mozilla *does* need to GET the image again, I can't think of any
legitimate reason that it should not send the same Referer header again.

3. I think that if the second GET fails (as it could be said to do when it gets
redirected to a text/html document), the cached image we must already have
(because we just had it) should be displayed. Even showing the HTML document the
second GET was redirected to would make more sense than the current behavior of
showing neither.

4. ImageLib (or whatever it is that's printing the URL in the browser window)
needs better error messaging so that it's obvious to the user that an error has
occurred in displaying the image.

It may very well be Mozilla bugs causing this behaviour.  However, it doesn't
happen at every Web site.  Since it doesn't ALWAYS happen there has to be
something different in the way that the "problem" Web sites' servers host the
images.  Once the difference(s) between a site that Mozilla has no problem with
and one with which Mozilla does have a problem can be isolated, it will be a big
step in figuring out what specific piece of Mozilla code needs to be looked at.
This is getting more frustrating every time I try to figure it out. I now have
successfully reproduced this bug on one of my own web servers with one of my own
images. However, it happes on one machine and not on another. These are both
running Linux Mozilla 0.9.9 (build 2002031008). Same document, same server, same
OS, same Mozilla build. Different result.

Here is the full transaction (minus the actual documents returned) from the
machine it doesn't work on:

> GET /outgoing/temp/testimg3.jpg HTTP/1.1
> Host: www.sharding.org
> User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.9) Gecko/20020310
> Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
> Accept-Language: en-us, en;q=0.50
> Accept-Encoding: gzip, deflate, compress;q=0.9
> Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
> Keep-Alive: 300
> Connection: keep-alive
> Referer: http://www.sharding.org/outgoing/temp/testim.html

< HTTP/1.1 200 OK
< Date: Fri, 15 Mar 2002 23:41:01 GMT
< Server: Apache
< Last-Modified: Fri, 15 Mar 2002 23:31:17 GMT
< ETag: "c6931-e98f-3c928445"
< Accept-Ranges: bytes
< Content-Length: 59791
< Keep-Alive: timeout=15, max=99
< Connection: Keep-Alive
< Content-Type: image/jpeg
< <data>

> GET /outgoing/temp/testimg3.jpg HTTP/1.1
> Host: www.sharding.org
> User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.9) Gecko/20020310
> Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
> Accept-Language: en-us, en;q=0.50
> Accept-Encoding: gzip, deflate, compress;q=0.9
> Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
> Keep-Alive: 300
> Connection: keep-alive
> If-Modified-Since: Fri, 15 Mar 2002 23:31:17 GMT
> If-None-Match: "c6931-e98f-3c928445"
> Cache-Control: max-age=0
 
< HTTP/1.1 302 Found
< Date: Fri, 15 Mar 2002 23:41:27 GMT
< Server: Apache
< Location: http://www.sharding.org/outgoing/temp/nono.html
< Keep-Alive: timeout=15, max=100
< Connection: Keep-Alive
< Transfer-Encoding: chunked
< Content-Type: text/html; charset=iso-8859-1
< <data>

> GET /outgoing/temp/nono.html HTTP/1.1
> Host: www.sharding.org
> User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.9) Gecko/20020310
> Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
> Accept-Language: en-us, en;q=0.50
> Accept-Encoding: gzip, deflate, compress;q=0.9
> Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
> Keep-Alive: 300
> Connection: keep-alive

< HTTP/1.1 200 OK
< Date: Fri, 15 Mar 2002 23:41:27 GMT
< Server: Apache
< Last-Modified: Wed, 06 Mar 2002 23:25:34 GMT
< ETag: "c692d-11f-3c86a56e"
< Accept-Ranges: bytes
< Content-Length: 287
< Keep-Alive: timeout=15, max=100
< Connection: Keep-Alive
< Content-Type: text/html
< <data>
 
In the time between the first GET and the second GET, mozilla displays the
image. When the second GET is done, the image disappears and only the URL text
is shown.
 
And here is the full transaction (minus the actual documents returned) from the
machine it does work on:
 
> GET /outgoing/temp/testimg3.jpg HTTP/1.1
> Host: www.sharding.org
> User-Agent: Mozilla/5.0 (X11; U; Linux i386; en-US; rv:0.9.9) Gecko/20020310
> Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,video/x-mng,image/png,image/jpeg,image/gif;q=0.2,text/css,*/*;q=0.1
> Accept-Language: en-us, en;q=0.50
> Accept-Encoding: gzip, deflate, compress;q=0.9
> Accept-Charset: ISO-8859-1, utf-8;q=0.66, *;q=0.66
> Keep-Alive: 300
> Connection: keep-alive
> Referer: http://www.sharding.org/outgoing/temp/testim.html

< HTTP/1.1 200 OK
< Date: Fri, 15 Mar 2002 23:42:33 GMT
< Server: Apache
< Last-Modified: Fri, 15 Mar 2002 23:31:17 GMT
< ETag: "c6931-e98f-3c928445"
< Accept-Ranges: bytes
< Content-Length: 59791
< Keep-Alive: timeout=15, max=100
< Connection: Keep-Alive
< Content-Type: image/jpeg
< <data>


That's it. Only one GET and nothing more. Displays the image fine.


Well.  That makes it almost impossible to tell what's causing this doesn't it? 
What if, for now, we simply accept the fact that sometimes (with some servers
and/or some workstations) a 2nd GET without a Referer header (for whatever
reason) will always take place.  I can think of only three things that could be
done:

1. Detect Mozilla's 2nd GET and abort it before it occurs.

2. Allow the 2nd GET to take place but do not allow it to leave out the Referer
header.

3. Work with the image library to provide better diagnostic feedback.

Are any of the above already existing bugs on their own?  If not, perhaps they
should be logged and this bug made dependant on them.  

However, none of these solutions is really an "answer".  The first two mask the
symptoms, rather than treating the cause, and the third is simply a method of
increased investigation...
Sean: Maybe timing is the key?
Can you measure average response time for both servers and compare them?
Timing is a possibility. (However, remember that both requests went to the same
server).

The machine it doesn't work on is on the same LAN (100 megabit full duplex
switched) with the web server.

The machine it does work on is on the other end of a 256kbps DSL link. 

So, if it's timing, then slower seems to make it more likely to work.

Feel free to test with my page at
http://www.sharding.org/outgoing/temp/testim.html (no porn involved)


Does this relate in any way to bug 118219? While I don't see the URI of the
image in the test cases in that bug I am seeing the double requests. It seems
the shift-reload scenario is a bit more reproducable as well.
Note that the behaviour of this bug has changed.  Previously, the image would
load, be immediately replaced with the text of the URL of the image, and would
be displayed properly after a Shift-Reload.

Using the testcase from comment 36, the following now happens.  It loads, and is
immediately replaced with this altered text:

The image "http://www.sharding.org/outgoing/temp/testimg3.jpg" cannot be
displayed because it contains errors.

At some point in recent weeks (I haven't been checking on this bug daily), code
was checked in to have Mozilla show the "because it contains errors" text.  In
this testcase, what error is it referring to?  Up until the image is completely
loaded, it looks fine to me.

Also note that now not even a Shift-Reload of this test case shows the image. 
It simply gives the error text again.  It looks like the problem has now
actually got WORSE.  At least before a Shift-Reload would bring it up.  Now you
can't get it at all.  Is this related to the code check-in that resulted in the
"because it contains errors" text?
I've spent a ton of time tracing mozilla (really just putting in a bunch of
printfs in nsHttpChannel.cpp, nsLoadGroup.cpp, nsImageBoxFrame.cpp,
imgLoader.cpp,  nsImageFrame.cpp, etc. because I don't have enough memory to
effectively use the debugger) to try to figure out what's going on here. I still
haven't successfully tracked down what's causing the second request. Part of the
problem, of course, is that I'm having to devote most of my energy to learning
how the code works in general because I've never touched this part of Mozilla
before. Hopefully I'll have some more time to dig into it soon, but I think I've
used up my spare time for the moment.
Not sure if this is relevant (if it isn't, I'd be very appreciative if someone
who knows that would tell me), but I've found that the second time around,
nsHttpChannel::Connect() is calling nsHttpChannel::CheckCache() which is setting
mCachedContentIsValid to false because VALIDATE_ALWAYS is set in mLoadFlags
(because loadPolicy == "always"? Where is that set? That seems to come from
nsXULAtoms::validate, and the only place I can find "validate" set is in
xpfe/browser/resources/content/navigator.xul. But those all have it set to
"never"). 

havin mCachedContentIsValid be false then causes nsHttpChannel::Connect() to go
to the net for the file. That second time around is the time we do the GET
without the referer, which then causes the server (in certain cases) to send
back an error instead of the image we saw before. 
Could someone change the URL on this bug to
http://www.sharding.org/outgoing/temp/testim.html ? I think that more accurately
demonstrates the problem that has been discussed in the bulk of this bug. I
don't have permission to change it.

(Also note that it should *not* point directly to the image -- you have to go to
that page and click the link from there to see the behavior in question)

Ok, I changed the URL.

Also, here's a way to reproduce with this particular link:
1) Go to http://www.sharding.org/outgoing/temp/testim.html 
2) Click on the Link
3) If you see the image, click shift-reload until you see the bug.

Expected results:
We see the image every time.

Actual results:
We sometimes see the URL of the image instead of the image.
URL: http://www.subpop.com/history/images/... → http://www.sharding.org/outgoing/temp...
I just installed mozilla rc2 (latest version available today), and had this 
same problem.  Anyway, i remember someone mention that when using mod_rewrite 
(usually thats how these images are protected, and for some reason mozilla is 
having problems with them) on apache, mod_rewrite sends some different headers 
or confirmation codes.  i have no idea what the header differences are, but 
guess that'll be a starting point.  Maybe mozilla gets confused once in a 
while.  although this problem doesn't seem to happen all the time... just on 
background images, initially.   (i'm on a win_xp/intel machine)
*** Bug 121084 has been marked as a duplicate of this bug. ***
Blocks: 151432, 153633
See discussion from duplicate bug 121084 on this issue - quite informative.

Added blocks and keywords and Target Milestone from bug 121084.  CCing Darin.

Should component be changed to Networking: HTTP as per other bug?
Keywords: mozilla1.0 → mozilla1.1, nsbeta1, perf, regression, relnote
Target Milestone: Future → mozilla1.1beta

*** This bug has been marked as a duplicate of 121084 ***
No longer blocks: 151432, 153633
Status: NEW → RESOLVED
Closed: 22 years ago
Keywords: nsbeta1, perf, regression, relnote
Resolution: --- → DUPLICATE
Guillaume: Hopefully this is okay with you.  (See bug 121084 comment 81 and bug
121084 comment 83.)
No problem with me on putting this as a dupe of bug 121084.

The "cache: Images requested twice" description make it look a lot like 
what I described in comment #6.

BTW, Those who voted for this bug are welcomed to vote for bug 121084 
instead.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: