754080 - Add support for testing plugin blocklists to the desktop web runtime

Status: RESOLVED WORKSFORME

(Firefox Graveyard :: Webapp Runtime, defect, P2)

Description

[Jason Smith [:jsmith]]

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.

Comment 1

[Jason Smith [:jsmith]]

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.

Comment 2

[Jason Smith [:jsmith]]

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.

Comment 3

[Jason Smith [:jsmith]]

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.

Comment 4

[Jason Smith [:jsmith]]

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

[Jorge Villalobos [:jorgev] (he/him)]

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

Comment 6

[Jason Smith [:jsmith]]

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

[Jorge Villalobos [:jorgev] (he/him)]

The problem is that you entered the Mac OS X block on Windows.

Comment 8

[Jason Smith [:jsmith]]

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.