1) Start from fresh Firefox profile, preferably with no Java installed 2) Install Adobe Acrobat Reader (we're going to use it to know the blocklist took) 3) Change over to the testing blocklist as described in https://wiki.mozilla.org/Extension_Blocklisting:Testing#Testing_by_pointing_to_a_testfile 4) Restart and allow it time to take (it'll notify you Acrobat is deactivated) 5) Navigate to http://www.pianoworld.com/fun/javapiano/javapiano.htm/ 6) Notification bar will ask you to install missing Java plugin 7) Install the plugin (Sun installer should run to completion) 8) Plugin Finder Service will tell you Java plugin is now installed. 9) Hit Finish 10) You'll be returned to page. Notification bar asks if you'd like to install missing Java plugin. 11) GOTO 7 :) So multiple issues here: a. We ask to install a hard-blocked plugin, even if it's already installed. b. We claim we have installed a hard-blocked plugin implying its usable. c. When page is loaded w/ blocked plugin, we don't inform user it's blocked d. GOTO considered harmful. c is a particular problem in cases where a plugin is blocked prior to a user installing it, since we seem to only notify if an -installed- plugin is newly blocked. There'll be no notification that the newly installed plugin is not working because of blocklists, so they'll wonder why the install mysteriously failed. I'd expect us to potentially put up the block notification on either a change of blocklist or a change of plugin loadout, rather than just the former. Behavior observed in Win7, but likely applies to other OSes as well.
This was Firefox 7.0 release, btw: Build identifier: Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0
The plugin finder database and the blocklist database are totally separate right now and Firefox has no way to know that an entry in one should override the other. We should be removing plugins from the PFS list if we are hard blockling them. If we haven't please file a bug against the PFS component to have the offending plugin removed. The only behaviour we can control client-side is that we shouldn't be showing the PFS notification when the plugin is already installed but blocklisted
Strange, the applet tag on this page correctly shows the blocked UI: http://www.colinp.mistral.co.uk/java11.htm
Ok, narrowed this down, this is kind of a website/plugin issue but maybe we have to take care of it ourselves. The issue is that the java file that the page in comment 0 attempts to use (http://www.pianoworld.com/fun/javapiano/Piano.class) is reported as having a content type of application/java-vm. Unfortunately the Java plugin (at least the one I have on OSX and Windows) doesn't claim to support this, it supports application/x-java-vm so as far as Firefox is concerned we don't have the plugin installed for that applet so it is correctly offering to hunt one down.
(In reply to Dave Townsend (:Mossop) from comment #4) [...] > a content type of application/java-vm. Unfortunately the Java plugin (at > least the one I have on OSX and Windows) doesn't claim to support this, it > supports application/x-java-vm so as far as Firefox is concerned we don't > have the plugin installed for that applet so it is correctly offering to > hunt one down. On Linux, the IcedTea plugin similarly supports only MIME types of the form application/x-something, the first of which (in the order listed in about:plugins) is application/x-java-vm. FAYT doesn't find the string on/j anywhere in my about:plugins.
Resolving old bugs which are likely not relevant any more, since NPAPI plugins are deprecated.