Last Comment Bug 755554 - Only enable flash within the desktop runtime, all other plugins should not be allowed to run
: Only enable flash within the desktop runtime, all other plugins should not be...
Status: VERIFIED FIXED
[blocking-webrtdesktop1+], [qa!]
: dev-doc-needed
Product: Firefox Graveyard
Classification: Graveyard
Component: Webapp Runtime (show other bugs)
: unspecified
: All All
: P1 enhancement
: Firefox 16
Assigned To: Myk Melez [:myk] [@mykmelez]
: Jason Smith [:jsmith]
Mentors:
Depends on: 755551
Blocks: 763783 773685 1131368
  Show dependency treegraph
 
Reported: 2012-05-15 15:46 PDT by Jason Smith [:jsmith]
Modified: 2016-03-21 12:39 PDT (History)
11 users (show)
See Also:
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
patch v1: specifies allowed types (344 bytes, patch)
2012-07-11 11:33 PDT, Myk Melez [:myk] [@mykmelez]
felipc: review+
myk: checkin+
Details | Diff | Review

Description Jason Smith [:jsmith] 2012-05-15 15:46:45 PDT
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] 2012-05-28 22:57:30 PDT
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] 2012-05-29 14:19:02 PDT
I'm working on 755551 now, which I suspect will make this a simple pref change for webrt
Comment 3 Andrew Overholt [:overholt] 2012-06-14 12:05:41 PDT
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] 2012-07-10 17:08:27 PDT
Once the blocking bug is fixed, this is a simple pref change that I can make.
Comment 5 John Schoenick [:johns] 2012-07-11 09:00:40 PDT
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] 2012-07-11 11:33:48 PDT
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)?
Comment 7 Jason Smith [:jsmith] 2012-07-11 11:51:12 PDT
(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] 2012-07-12 13:26:08 PDT
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] 2012-07-12 14:04:48 PDT
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] 2012-07-13 05:32:17 PDT
https://hg.mozilla.org/mozilla-central/rev/741b4ebd050f
Comment 11 Benjamin Smedberg [:bsmedberg] 2012-07-13 06:09:01 PDT
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] 2012-07-13 09:36:25 PDT
(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] 2012-07-16 09:36:00 PDT
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] 2012-07-16 10:44:37 PDT
Verified on Win 7, OS X 10.7, Ubuntu 12.

Note You need to log in before you can comment on or make changes to this bug.