Closed
Bug 754080
Opened 13 years ago
Closed 12 years ago
Add support for testing plugin blocklists to the desktop web runtime
Categories
(Firefox Graveyard :: Webapp Runtime, defect, P2)
Firefox Graveyard
Webapp Runtime
Tracking
(Not tracked)
RESOLVED
WORKSFORME
Firefox 15
People
(Reporter: jsmith, Unassigned)
References
()
Details
Tracker bug for implementing support for testing plugin blocklists for the desktop web runtime. Not entirely sure how to implement this, but details on what's needed in firefox is listed here - https://wiki.mozilla.org/Blocklisting/Testing. This is incredibly important to support, as we need to ensure that our blocklisted plugins do not become active in the web runtime. This does relate to k9o, as flash is a P1 requirement for the desktop web runtime, and there are old versions of flash that are blocklisted for various reasons.
Reporter | ||
Updated•13 years ago
|
Keywords: meta,
productwanted
Reporter | ||
Updated•13 years ago
|
blocking-kilimanjaro: --- → ?
Reporter | ||
Comment 1•13 years ago
|
||
Flagging productwanted for the same reasons that other plugin bugs were flagged this way - We need to know what plugin support we will have for the first release of the desktop web runtime and what features could be in the future.
Reporter | ||
Updated•13 years ago
|
Reporter | ||
Comment 2•13 years ago
|
||
Flash is the only plugin in the scope for the desktop runtime. All others will be implicitly disabled. This implementation just needs to provide me (the tester) a way to configure a plugin blocklist for flash versions and test that proper flash versions of blocklisted and others are not.
Keywords: productwanted
Assignee | ||
Updated•13 years ago
|
Component: Desktop Runtime → Webapp Runtime
Product: Web Apps → Firefox
Updated•13 years ago
|
blocking-kilimanjaro: ? → ---
Reporter | ||
Comment 3•13 years ago
|
||
Note - I've found a way to make this MUCH easier for testing - Firefox relies on a blocklist.xml file in the firefox installation directory to determine if a plugin is blocklisted. For testing this in the web runtime, we could simply just generate the blocklist.xml file via firefox through the traditional blocklist steps.
The only thing left needed to close this as a WORKSFORME is that a plugin known to be blocked is blocked in the web runtime.
Reporter | ||
Comment 4•13 years ago
|
||
Jorge - I'm looking to test whether the web app runtime for desktop does blocklisting correctly. How could I configure the blocklist.xml to block say, all versions of Java? I'm having some difficulty getting a test XML file setup so that I could verify blocklisting works correctly in the runtime (I'm not sure if it does or not).
Comment 5•13 years ago
|
||
On Mac:
> <pluginItem blockID="p100">
> <match name="filename" exp="JavaAppletPlugin\.plugin" />
> <versionRange minVersion="0" maxVersion="*" severity="1"></versionRange>
> </pluginItem>
On Windows:
> <pluginItem blockID="p200">
> <match name="filename" exp="npjp2\.dll" />
> <versionRange minVersion="0" maxVersion="*" severity="1"></versionRange>
> </pluginItem>
Just make sure that the blockID is unique and the nodes are inserted in the <pluginItems> section. For Flash, you would want the filename expression to be NPSWF[0-9_]*\.dll
Reporter | ||
Comment 6•13 years ago
|
||
Here's what I did on Windows to blocklist.xml file in the Nightly folder and profile folder:
<pluginItem blockID="p899999">
<match name="filename" exp="JavaPlugin2_NPAPI\.plugin" />
<versionRange minVersion="0" maxVersion="*" severity="1"></versionRange>
</pluginItem>
Then, I started up firefox with the profile with this blocklist.xml. Nothing happened. I went to a Java Applet and it appeared just fine (no errors). I did not see the blocklist user interface come up at all. I have the latest version of the Java plugin installed.
Comment 7•13 years ago
|
||
The problem is that you entered the Mac OS X block on Windows.
Updated•13 years ago
|
Priority: -- → P2
Target Milestone: --- → Firefox 15
Reporter | ||
Comment 8•12 years ago
|
||
Blocklist testing is confirmed to be available, as I did the following, which should work with the runtime in theory (but in reality it didn't, making bug 755557 open):
I modified blocklist.xml in the installation directory and the profile directory, causing a hardblock of flash versions 10.2.159.1 or earlier and had a flash version 10.2.152.32 installed on my machine:
<pluginItem blockID="p94">
<match name="filename" exp="(NPSWF32\.dll)|(Flash\ Player\.plugin)" /> <versionRange minVersion="0" maxVersion="10.2.159.1" severity="2"></versionRange>
</pluginItem>
</pluginItems>
On desktop firefox, a hard block was invoked immediately on start-up, preventing usage of flash. Going to http://mozqa.com/data/firefox/plugins/flash/ and running the swf tests showed that the block worked on desktop firefox. Doing this behavior should correspondingly work in the web runtime, as the web runtime should be able to get access to blocklist.xml either in the profile directory or the installation directory.
Resolving as worksforme - this is possible to test.
Reporter | ||
Updated•12 years ago
|
Summary: [meta] Add support for testing plugin blocklists to the desktop web runtime → Add support for testing plugin blocklists to the desktop web runtime
Assignee | ||
Updated•9 years ago
|
Product: Firefox → Firefox Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•