There's code scattered around that deals with <object><param name="pluginurl"></object> as a special case (vs <object> without such a <param>). It looks like the purpose of this is because the Default Plugin can use the <param> to install plugins itself. And so there's special case code to allow loading the Default Plugin in these cases, and suppress the newer PFS UI. Bug 533891 will be removing the Default Plugin, in the meantime we should just go ahead and remove this related special-case code since it doesn't end up used, and can confusingly suppress the usual "missing plugin" UI. IE, Safari, and Chrome seem to treat <objects> with/without this URL equally.

Will we still look at that param in the PFS?

I don't think PFS looks at the "pluginurl" param. I looked at all the hits for that string in the tree, and outside of /modules/plugin/default the param value didn't seem to be used for anything (just side-effects when the param *name* is present). It looks like PFS does use a "pluginspage" param when present, but that's not used in the various places where we specialcase "pluginurl".

Ah, hmm. pluginspage is a webpage to navigate to; pluginurl is the place to download the plugin from directly. I guess we don't really want the latter, yeah.

This is annoying as we don't display the usual 'you need a plugin to display this content' message for <object> tags *unless* we have this otherwise-unused param. I'm going to fix this along with the numerous followups to bug 745030

Comment on attachment 653582 [details] [diff] [review] Remove special handling for object 'pluginurl' param The PFS no longer uses this, but our CSS only binds error frames to objects that have a pluginurl parameter - so the visible change here is now we'll actually display missing plugin errors for <object> tags without this param

Comment on attachment 653582 [details] [diff] [review] Remove special handling for object 'pluginurl' param Look fine, though you'll be wanting review from a content peer for the /content/* changes. Might be worth keeping/adding a test with |pluginurl| specified, just to ensure its presence doesn't make us asplode?

(In reply to John Schoenick [:johns] from comment #6) > The PFS no longer uses this, but our CSS only binds error frames to objects > that have a pluginurl parameter - so the visible change here is now we'll > actually display missing plugin errors for <object> tags without this param Then the alternate content will never be displayed? It doesn' t look correct per spec.

(In reply to Masatoshi Kimura [:emk] from comment #8) > (In reply to John Schoenick [:johns] from comment #6) > > The PFS no longer uses this, but our CSS only binds error frames to objects > > that have a pluginurl parameter - so the visible change here is now we'll > > actually display missing plugin errors for <object> tags without this param > Then the alternate content will never be displayed? It doesn' t look correct > per spec. We'll still show alternate content if it exists, otherwise we'll show our custom error frame

Comment on attachment 653582 [details] [diff] [review] Remove special handling for object 'pluginurl' param https://hg.mozilla.org/integration/mozilla-inbound/rev/a6f040934c99

Comment on attachment 653582 [details] [diff] [review] Remove special handling for object 'pluginurl' param Bounced due to a reftest failure: https://hg.mozilla.org/integration/mozilla-inbound/rev/ad0a615541cf I only realized this lacked a try push after hitting inbound, oops! Followup to fix that and actually address c7 incoming...

Comment on attachment 653582 [details] [diff] [review] Remove special handling for object 'pluginurl' param https://hg.mozilla.org/integration/mozilla-inbound/rev/4082461196b0 Try: https://tbpl.mozilla.org/?tree=Try&rev=7ac49c949717

Comment on attachment 653582 [details] [diff] [review] Remove special handling for object 'pluginurl' param [Approval Request Comment] Bug caused by (feature/regressing bug #): N/A User impact if declined: N/A Testing completed (on m-c, etc.): On m-c Risk to taking this patch (and alternatives if risky): Causes <object> tags to display the grey missing-plugin frame in many more cases, which could possibly be unwanted on some sites. The <embed> tag already behaves this way, and chrome displays the missing-plugin frame more aggressively than us, so the risk of this being significant is fairly low. String or UUID changes made by this patch: None This blocks landing bug 800018 on beta

Comment on attachment 653582 [details] [diff] [review] Remove special handling for object 'pluginurl' param [Approval Request Comment] If this is not a sec:{high,crit} bug, please state case for ESR consideration: This is needed if we want to take bug 800018 on 17esr, otherwise is not worth uplifting. See comments there.

Comment on attachment 653582 [details] [diff] [review] Remove special handling for object 'pluginurl' param [Triage Comment] Blocks bug 800018 from landing, approving for all branches.

https://hg.mozilla.org/releases/mozilla-aurora/rev/fb467da6a9cc https://hg.mozilla.org/releases/mozilla-beta/rev/ce4d9f008712 https://hg.mozilla.org/releases/mozilla-esr17/rev/f4ce7d17c6ed