Closed Bug 92629 Opened 23 years ago Closed 15 years ago

Page Info does not send referrer for uncached images (media panel)

Categories

(SeaMonkey :: Page Info, defect)

Product:
SeaMonkey
Component:
Page Info
Platform:
x86
Windows NT
Type:
defect
Priority:
Not set
Severity:
minor

Tracking

(Not tracked)

Status:
RESOLVED WORKSFORME

People

(Reporter: bns_robson, Assigned: db48x)

References

(
URL
)

Details

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.
Assignee: blake → jesse
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?
QA Contact: sairuh → benc
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...
Component: XP Apps: GUI Features → Page Info
QA Contact: benc → pmac
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".
Assignee: jruderman → db48x
Summary: Images not displayed by Page Info and Frame Info → Page Info does not send referrer for uncached images (media panel)
Severity: normal → minor
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.
Blocks: 61660
Product: Browser → Seamonkey
QA Contact: pmac
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
Status: NEW → UNCONFIRMED
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.
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.