Closed Bug 729009 Opened 10 years ago Closed 10 years ago

Send plugin src as plugin sub-request's referer


(Core Graveyard :: Plug-ins, defect)

12 Branch
Not set


(firefox13+ verified)

Tracking Status
firefox13 + verified


(Reporter: dindog, Assigned: benjamin)



(Keywords: regression, Whiteboard: [qa!])


(2 files)

This is what other browsers do. After Bug 410904 patch, it send document's URI, which will meet some error, especially for the plugin embed in a different domain page.

You can see the different referer in the testcase of Bug 410904:

This is a embed flash video which only firefox fail to play:

All bug depend on Bug 410904 is marked fixed or dupe, decided to file a new one.
Mozilla/5.0 (Windows NT 6.1; WOW64; rv:13.0) Gecko/13.0 Firefox/13.0a1 ID:20120220074932

Error in Web console:
[18:11:59.101] GET [HTTP/1.1 403 Forbidden 590ms]
Obviously the behavior isn't specified, but I don't believe that sending the plugin URL is the correct behavior: for the most part plugins don't introduce a new browsing context.
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #2)
> Obviously the behavior isn't specified, but I don't believe that sending the
> plugin URL is the correct behavior: for the most part plugins don't
> introduce a new browsing context.

It is not specified, but Firefox is eccentric in all these years, hoping Bug 410904 fixed that, but now only make it even weird than before.

Just check Opera using the test case above, same as IE and Chrome:

Simple decision, heh?
> for the most part plugins don't introduce a new browsing context.

Neither do SVG resource documents or stylesheets, yet I'm pretty sure that @import in a stylesheet sends the stylesheet URI as the referrer and that resources loaded from SVG resource documents send the resource doc URI as the referrer.

Actually, CSS background images and the like also use the stylesheet as the referrer.  See bug 249168.

For what it's worth, I think sending the plug-in URI as the referrer for requests the plug-in makes is perfectly reasonable...
I see Bug 724465 request landing for a aurora, if we change GET referer, for consistence, POST send nothing seem weird...
I hope a consensus is reached here soon. This change in behavior has unfortunately broken the 'embedded highlights' functionality of one of my favorite websites,, and I would hate to see one or even two releases of Firefox stay incompatible with it (if this turns into an evangelism issue it's probably that would have to be contacted). I have set network.http.sendRefererHeader = 1 as a workaround, but I doubt most users will find this option.
Another example to test:
It's a website similar to iTunes or Deezer to buy/download music.

If you use FF10, the Flash player is visible on the right:

If you use FF13, the Flash player is not visible and the website asks you to update your Flash player:

network.http.sendRefererHeader = 1 doesn't work as workaround in FF13.
Forget my previous comment, Flash wasn't enabled. :|
Base on other browsers actual behavior and comment 4, isn't the choice  obviously?

Because of Bug 410904 and Bug 724465, some plugin will behave different from previous versions of Fx and also other browsers.

Less than two weeks, current nightly will move to aurora, more extra review needed by then.
Josh decided that we should send the plugin src as the referer (when there is one). However, when trying to implement this I discovered that nsNPAPIPluginInstance::mURI/SetURI/GetURI are dead code, and so it doesn't appear that the plugin instance actually knows its URI after its finished delivering the initial stream.

Josh, is there an alternate way of knowing the plugin src from the instanceowner or something? If not, should I be resurrecting SetURI and make it correct?
Assignee: nobody → benjamin
Attachment #604503 - Flags: review? → review?(joshmoz)
Attachment #604503 - Flags: review?(joshmoz) → review+
Comment on attachment 604517 [details] [diff] [review]
Part A - Make the Referer be the plugin source when available, rev. 1

Review of attachment 604517 [details] [diff] [review]:

::: content/base/src/nsObjectLoadingContent.cpp
@@ +2070,5 @@
>    return rv;
>  }
> +nsObjectLoadingContent::GetSrcuri(nsIURI** aURI)

Can we capitalize URI in the method name? Looks pretty odd without it.
Attachment #604517 - Flags: review?(joshmoz) → review+
Closed: 10 years ago
Resolution: --- → FIXED
Whiteboard: landed on inbound
Target Milestone: --- → mozilla13
Flags: in-testsuite+
Whiteboard: [qa+]
Verified that the embed flash video from the Description plays on Firefox 13 beta 3.
Verified as fixed on Windows 7, Ubuntu 12.04 and Mac OS X 10.6:
Mozilla/5.0 (Windows NT 6.1; rv:13.0) Gecko/20100101 Firefox/13.0
Mozilla/5.0 (X11; Linux i686; rv:13.0) Gecko/20100101 Firefox/13.0
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.6; rv:13.0) Gecko/20100101 Firefox/13.0
Whiteboard: [qa+] → [qa!]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.