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

VERIFIED FIXED in Firefox 16

Status

Firefox Graveyard
Webapp Runtime
P1
enhancement
VERIFIED FIXED
5 years ago
a year ago

People

(Reporter: jsmith, Assigned: myk)

Tracking

({dev-doc-needed})

unspecified
Firefox 16
dev-doc-needed
Dependency tree / graph

Details

(Whiteboard: [blocking-webrtdesktop1+], [qa!])

Attachments

(1 attachment)

(Reporter)

Description

5 years ago
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.
(Reporter)

Updated

5 years ago
Depends on: 755551
Component: Desktop Runtime → Webapp Runtime
Product: Web Apps → Firefox
(Reporter)

Updated

5 years ago
blocking-kilimanjaro: --- → ?

Updated

5 years ago
blocking-kilimanjaro: ? → +
(Reporter)

Updated

5 years ago
Priority: -- → P1
Whiteboard: [blocking-webrtdesktop1+]
(Reporter)

Updated

5 years ago
Target Milestone: --- → Firefox 15
(Assignee)

Comment 1

5 years ago
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.
I'm working on 755551 now, which I suspect will make this a simple pref change for webrt
Assignee: nobody → jschoenick
(Assignee)

Updated

5 years ago
Blocks: 763783
(Assignee)

Updated

5 years ago
Target Milestone: Firefox 15 → Firefox 16
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.
(Reporter)

Updated

5 years ago
tracking-firefox16: --- → ?

Updated

5 years ago
tracking-firefox16: ? → +
(Reporter)

Updated

5 years ago
QA Contact: desktop-runtime → jsmith
(Assignee)

Comment 4

5 years ago
Once the blocking bug is fixed, this is a simple pref change that I can make.
Assignee: jschoenick → myk
Status: NEW → ASSIGNED
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
(Assignee)

Comment 6

5 years ago
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)?
(Reporter)

Comment 7

5 years ago
(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.
(Assignee)

Comment 8

5 years ago
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.
Attachment #641136 - Flags: review?(felipc)
Attachment #641136 - Flags: review?(felipc) → review+
(Assignee)

Comment 9

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

https://hg.mozilla.org/integration/mozilla-inbound/rev/741b4ebd050f
Attachment #641136 - Flags: checkin+
(Reporter)

Updated

5 years ago
Whiteboard: [blocking-webrtdesktop1+] → [blocking-webrtdesktop1+], [qa+]
https://hg.mozilla.org/mozilla-central/rev/741b4ebd050f
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
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.
(Assignee)

Updated

5 years ago
Blocks: 773685
(Assignee)

Comment 12

5 years ago
(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.
(Reporter)

Comment 13

5 years ago
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.
Keywords: dev-doc-needed
(Reporter)

Comment 14

5 years ago
Verified on Win 7, OS X 10.7, Ubuntu 12.
Status: RESOLVED → VERIFIED
Whiteboard: [blocking-webrtdesktop1+], [qa+] → [blocking-webrtdesktop1+], [qa!]
tracking-firefox16: + → -
Blocks: 1131368
Product: Firefox → Firefox Graveyard
You need to log in before you can comment on or make changes to this bug.