Go to http://www.snoweye.com/ and select one of the regions using the left hand frame (I selected France, Rest of Haute Savoie). The right hand frame now shows pictures from some web cams. Right click on the frame showing the pictures and select View Frame Info. Select the Images Tab. This shows the URLs used to get the pictures. Click on one of the URLs. The bottom of the Page Info window should show the picture. Instead it displays an error message generated by the www.snoweye.com site. The same happens if you open one of the frames as a page and do view page info e.g. http://www.snoweye.com/cgi-bin/pagegen.cgi?page=fr-hautesavoie&index=true Note that the URLs for the pictures are calls to CGI scripts that I think check the referrer URL. My guess as to what is happening is that 1) Page info is not getting the picture from the cache and is requesting it again from the site. 2) The re-request does not contain, as the refering URL, the correct URL for the Page/Frame that loads the picture. I think this should be fixed by making Mozilla cache the picture and have page info get the picture from the cache.

-> Jesse, if not yours, give to Daniel.

hrm, i cannot repro using 2001.08.06.0x bits on mac, winnt or linux. is this still a problem? i tested going to www.snoweye.com and selecting the France - Rest of Haute Savoie...

I was running 0.9.2 when I reported the bug. Since then 0.9.3 has been released and I'm now running that. The behavour has changed in 0.9.3 but it's still incorrect. It now goes to the cache and will display images that are still in the cache and have not expired. It doesn't display anything for images that are not in the cache or are in the cache and have expired. My cache settings are memory cache 4096 Kbytes, disk cache 50000 Kbytes and compare pages automatically. 1) I opened two windows and showed the URL about:cache in one and the URL http://www.snoweye.com/cgi-bin/pagegen.cgi?page=fr-hautesavoie&index=true in the other. 2) I cleared both caches 3) I reloaded the about:cache window. The disk cache was empty and the memory cache contained only crome: URLs 4) I reloaded the snoweye window and then the about:cache window. Note the http://www.snoweye.com/cgi-bin/url.cgi?fr-hautesavoie,1,4 etc URLs give http redirects to the resort sites that actually host the images. The actual images were in the disk cache and redirecting URL were in the memory cache. The disk cache shows some of the images expire immediately (e.g. Lac d'Annecy http://www.hoteldulac.com/img/ispy.jpg) and some don't (e.g. Les Carroz http://www.carroz.com/Capt.0.jpg). The expiry dates on the redirecting URL are the same as for the image they redirect to. 5) I then viewed page info. Only the non-expired images were displayed. Nothing was displayed for the other images. 6) Without closing the page info window, I cleared the cache. Now nothing was displayed for any image. p.s. I noticed the dates shown by about:cache were wrong. They are in U.S. mm/dd/yy format when they should be shown as U.K. dd/mm/yy. I'll look to see if there's already a bug on this. If not I'll file one.

benc, should this go over to the cache folx?

Dunno, lets ask them...

No, I don't think this is a cache problem. You might try imgLib. Pav, what do you think? There isn't a bug on the date format. I hoped we had somekind of xp date format routine, but I couldn't find one...

Bruce, could you try this in a more recent build? it should work pretty much the way you expect, though it'll has to go grab the expired images off the net. (it shows a placeholder in the mean time)

I am using Mozilla on Solaris and I have a similar problem. My build is 2002041422 for Solaris 2.6. If I visit http://www.volny.cz/dumka/0418dum.htm and click on Page Info -> Media I can see only some of the pictures from that page. I observed that the "visible" pictures are centered - either there is argument align=center or align=absmiddle in the IMG tag.

The bug seems to be fixed for Solaris 2.6. Build 2002050522.

This looks like a missing- or bogus-referrer problem. If I do a "copy image location" on one of the images at http://www.snoweye.com/cgi-bin/pagegen.cgi?page=fr-hautesavoie&index=true and paste into the location bar, I get "Unauthorised: This script may not be invoked except from the www.snoweye.com site".

Is it still occuring? I wouldn't be suprised if necko is getting clever and sending chrome://navigator/content/pageInfo.xul as the referrer, since that's technically correct. Someone should sniff their traffic and find out. If there's a way to change it, it'll require a bit of a rewrite as far as Page Info is concerned, because right now it's just creating an image tag with the right url, and letting layout worry about the rest.

I was able to reproduce this bug yesterday using a build from two weeks ago and the steps in comment 3. I don't mind if you future this bug.

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614

WFM => Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.9.1pre) Gecko/20090617 SeaMonkey/2.0b1pre Probably fixed by the page info rewrite.