157796 - <embed> objects do not have referrer

Status: VERIFIED FIXED

(Core Graveyard :: Plug-ins, defect, P3)

Description

[Sebastien Boisvert]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.0.0) Gecko/20020530
BuildID:    2002053012

<embed> objects in a page do not have the referrer header sent when a request is
sent to the server. Servers that check for a referrer will get a blank referrer,
and may reject the request (depending on server configuration). Some sites are
broken when using Mozilla because of this.
(could other tags also be affected by this?)

Reproducible: Always
Steps to Reproduce:
1.Go to given URL
2.Optional - click on button to bring up a javascript-created window with the
equivalent content.


Actual Results:  main page and/or new window: Image loads, midi file does not
load because referrer is not sent for the EMBEDed midi file - server rejects
request for midi file.

Expected Results:  main page and/or new window: Image loads, midi file loads also. 

-This works on IE (use ie.html for test on IE)

- Server checks to make sure that referrer is not blank when an object is
requested; denies request for objects if referrer is blank or from a different
domain.
- server can handle wyciwyg://-based referers (the fact that the image loads in
the javascript-created window proves this)

sidenote: I use proxomitron (http://proxomitron.org/) to follow the flow of
headers (which confirm the behavior noted), but a properly configured server log
should reveal the needed info.

Comment 1

[Bradley Baetz (:bbaetz)]

The <embed> stuff (which I traced down into plugins code) needs to QI the
channel they use for loading data to nsIHTTPChannel, and if that succeeds, call
SetReferrer with the source document URI.

Comment 2

[rubydoo123]

assigning to av

Comment 3

[Matthias Versen [:Matti]]

*** Bug 148268 has been marked as a duplicate of this bug. ***

Comment 4

[rubydoo123]

adding nsbeta1+ keyword

Comment 5

[av (gone)]

Attachment: patch v.1

Comment 6

[serge (gone)]

Comment on attachment 94429 [details] [diff] [review]
patch v.1

>+      nsresult res = doc->GetBaseURL(*getter_AddRefs(referrerURL));
could doc be == null?
why new res if we have rv?

Comment 7

[av (gone)]

Attachment: patch v.2

serge's comments addressed.

Comment 8

[serge (gone)]

Comment on attachment 94551 [details] [diff] [review]
patch v.2

>+    rv = NS_NewChannel(getter_AddRefs(channel), aURL, nsnull, loadGroup);
how about elimination of  delete listener here
by changing if to (NS_SUCCEEDED(rv))
>+    if (NS_FAILED(rv)) {
>       delete listener;
>-  }

Comment 9

[av (gone)]

Attachment: patch v.3

Comment 10

[serge (gone)]

Comment on attachment 94561 [details] [diff] [review]
patch v.3

r=serge

Comment 11

[Darin Fisher]

Comment on attachment 94561 [details] [diff] [review]
patch v.3

sr=darin

Comment 12

[av (gone)]

In the trunk.

Comment 13

[shrirang khanzode]

I tested this fix on 0812 trunk. What I see is the new window opens up now, the 
midi plays as well. However, when I open up the new window, the midi in the 
first window stops (which is ok), the second midi starts playin g(in the new 
window). So what I do is click on the play button on the first page to play the 
first midi expecting the second one to stop and the first one to begin playing. 
What is see is a freeze , the browser hangs for about 15-20 seconds before one 
of the two files begins playing again. Will that be a new bug ? reporter, could 
you please check this behaviour ? Thanks ! 
The original issue is definitely fixed, tho.

Comment 14

[Sebastien Boisvert]

I've just tried it on Win32 nightly build ID 2002081209 and everything now works
as expected. I have not noticed any problems (both midis play at the same time,
actually).

Please note that my registered midi plug-in is Quicktime 5.

Comment 15

[shrirang khanzode]

wonderful, verified.