rfe: per site/url hard blocking of certain plugins

[al_9x]

There exists a (perhaps) common pattern where a plugin (typically flash or silverlight) is used to provide some functionality, with a js/html fallback. The fallback is usually good enough. The hotmail wave4 compose page is an example of this, it uses silverlight for attachments with a fallback. The problem is that with NS, the page does not know to fallback. In all other cases that's exactly what you want, but in situations such as this, you want the page to think the plugin is missing and to just give you the fallback, here both the plugin and the placeholder are a nuisance.

This can be dealt with by surrogates on a case by case basis, but it might be useful to have a more generic way that hard blocks certain plugins per site or url. Can Fx already do this through CAPS or permissions.sqlite or any other way? What do you think of this for NS?

Here's a surrogate for hotmail:

Code: Select all

user_pref("noscript.surrogate.hotmail.sources", "@.mail.live.com/mail/EditMessageLight.aspx");
user_pref("noscript.surrogate.hotmail.replacement", "watch('_useSilverlightUpload',function(p,o,n){return false;});");

in cases where both work, how does "watch" compare with "__defineGetter__?" Any reason to prefer one over the other?

[Giorgio Maone]

Can Fx already do this through CAPS or permissions.sqlite or any other way? What do you think of this for NS?

I'm not sure about what "general" means here. What about pages which have multiple plugin instances, and acceptable fallbacks for some resources only?

in cases where both work, how does "watch" compare with "__defineGetter__?" Any reason to prefer one over the other?

[/quote]
They're almost equivalent, even though watch may be easier to use for read/write properties (you don't need to define both setter and getter), but doesn't work with DOM properties.

[al_9x]

Can Fx already do this through CAPS or permissions.sqlite or any other way? What do you think of this for NS?

I'm not sure about what "general" means here.

A plugin hard block is a generic solution that applies to this entire class of problems (forcing a fallback), a surrogate is specific to each page.

What about pages which have multiple plugin instances, and acceptable fallbacks for some resources only?

Obviously you wouldn't want a hard bock if you need the plugin on the same page, the question is, might the scenario where it would be useful, like this hotmail page, be common enough to warrant it. It's hard to say, all I can say is it would definitely save you time and effort relative to making a surrogate.