Closed Bug 98890 Opened 23 years ago Closed 23 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: 23 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: