755554 - Only enable flash within the desktop runtime, all other plugins should not be allowed to run

Status: VERIFIED FIXED

(Firefox Graveyard :: Webapp Runtime, enhancement, P1)

Description

[Jason Smith [:jsmith]]

Configure the underlying gecko core within the desktop web runtime to only allow versions of flash to run within the desktop web runtime. All other plugins should not be allowed to run. Depends on the underlying core implementation in bug 755551.

Comment 1

[Myk Melez [:myk] [@mykmelez]]

John: any chance you can tackle this plugin issue too?  It doesn't seem like there's a way for the runtime xulapp to do this; it seems like it would need support from the platform to make it happen.

Comment 2

[John Schoenick [:johns]]

I'm working on 755551 now, which I suspect will make this a simple pref change for webrt

Comment 3

[Andrew Overholt [:overholt]]

John is going to look into this in the next week or two and it shouldn't be too involved.  A patch during the 16 cycle is likely.

Comment 4

[Myk Melez [:myk] [@mykmelez]]

Once the blocking bug is fixed, this is a simple pref change that I can make.

Comment 5

[John Schoenick [:johns]]

A few things I noticed

Current versions of flash appear to claim both application/x-shockwave-flash (.swf) and application/futuresplash (.spl) which is a very legacy mimetype for flash, but I don't see harm in whitelisting both

Additionally, we need to make sure that the plugin finder service doesn't inject any messages for missing plugins that are not whitelisted, and decide if we even want it to offer to install flash in webrt contexts

Comment 6

[Myk Melez [:myk] [@mykmelez]]

Attachment: patch v1: specifies allowed types

This should be sufficient.  I'm not sure how to test it, though.  Is there an app that uses another plugin?  Or perhaps a simple way to embed content handled by another common plugin (like Quicktime or Java)?

Comment 7

[Jason Smith [:jsmith]]

(In reply to Myk Melez [:myk] [@mykmelez] from comment #6)
> Created attachment 641136 [details] [diff] [review]
> patch v1: specifies allowed types
> 
> This should be sufficient.  I'm not sure how to test it, though.  Is there
> an app that uses another plugin?  Or perhaps a simple way to embed content
> handled by another common plugin (like Quicktime or Java)?

Still digging for a specific app. For now, you could have your mykzilla app point to here - http://mainline.brynmawr.edu/Courses/cs110/spring2002/Applets/Examples.html and test that each java applet does not come up in the runtime. For testing a flash-based app, install the Mozilla QA WebRT Tester on apps.mozillalabs.com/appdir and see if you can view the swf files in firefox --> plugins --> flash.

Comment 8

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 641136 [details] [diff] [review]
patch v1: specifies allowed types

I'm having trouble cooking up an automated test for this, but I can confirm that it works in my manual testing.  I added a link to a page with Java applets to my Mykzilla test app:

http://mykzilla.org/app/

Click on the "Java applets" link, then click on an applet (f.e. the Smiley applet) with the Java plugin enabled on your computer.  When you do so in the browser, the Java applet runs, as it does in the runtime without this patch applied.  With this patch applied, however, the runtime displays the "missing plugin" icon with the message "A plugin is needed to display this content."


(In reply to John Schoenick [:johns] from comment #5)
> Additionally, we need to make sure that the plugin finder service doesn't
> inject any messages for missing plugins that are not whitelisted, and decide
> if we even want it to offer to install flash in webrt contexts

I'm not sure if it's the plugin finder service, but some code is injecting the "missing plugin" message.  It does not, however, offer to find the user an appropriate plugin.  The message could be better, but optimizing the message doesn't seem like a blocker, so let's deal with it in a followup bug.

Comment 9

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 641136 [details] [diff] [review]
patch v1: specifies allowed types

https://hg.mozilla.org/integration/mozilla-inbound/rev/741b4ebd050f

Comment 10

[Ed Morley [:emorley]]

https://hg.mozilla.org/mozilla-central/rev/741b4ebd050f

Comment 11

[Benjamin Smedberg]

What's the followup bug#? Displaying the missing plugin placeholder is definitely incorrect in this case: we should be displaying fallback content if there is any, and displaying nothing (probably treating the object as display:none) if there is no fallback content.

Comment 12

[Myk Melez [:myk] [@mykmelez]]

(In reply to Benjamin Smedberg  [:bsmedberg] from comment #11)
> What's the followup bug#? Displaying the missing plugin placeholder is
> definitely incorrect in this case: we should be displaying fallback content
> if there is any, and displaying nothing (probably treating the object as
> display:none) if there is no fallback content.

Indeed.  I filed followup bug 773685 on displaying the fallback content or nothing for unsupported plugins.

Comment 13

[Jason Smith [:jsmith]]

Flagging dev-doc-needed. I have a strong hunch we'll be asked this question for development of HTML 5 apps, so let's get this on MDN somewhere.

Comment 14

[Jason Smith [:jsmith]]

Verified on Win 7, OS X 10.7, Ubuntu 12.