User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.7) Gecko/20070914 Firefox/2.0.0.7
Currently the only way for a user to really disable plugins in Firefox is to install an extension that toggle the docShell.allowPlugins attribute. Unfortunately, this attribute is not enforced if the user either redirected to (or directly clicks on) a plugin-handled mime-type. There are many security reasons why a user would want to disable plugins selectively, including but not limited to attacks such as Dan Kaminsky's Flash/Java firewall tunneling exploits, and usage over either instututional proxies, and the Tor Project.
Reproducible: Always
Steps to Reproduce:
1. Install an extension that disables plugins with docShell.allowPlugins (such as Torbutton-alpha at http://torbutton.torproject.org/dev or PrefButton)
2. Visit a plugin-handled link, or visit a site that has a meta refresh to a plugin handled link (*.swf, *.pdf, etc etc)
3. Watch the plugin load despite having been disabled.
Actual Results:
Plugin loads.
Expected Results:
Plugin should not load.
Currently various hacks exist to block this behavior. NoScript and Torbutton-alpha both do the request.cancel() call, but this does not actually stop the plugin from loading. In particular, AcroRead still parses the URL arguments and performs some network operations before it can be cancelled, and cancelling it can even hang the browser in some situations...

I created a test extension and test page that demonstrates the bug. The test extension adds an item to the Tools menu that when clicked sets docShell.allowPlugins=false for the selected tab.
To reproduce:
1. install Test extension
2. open the test case (3rd attachment) and note that the Flash video loads
3. select "Disable plugins" from the Tools menu
4. re-load the test case and note that the Flash video does not load
5. click the link in the test case to browse directly to the Flash video. Note that the video loads even though allowPlugins is set to false.

Turns out there is a hidden pref that may address this. plugin.disable_full_page_plugin_for_types seems like it should prevent the direct-link load case for a list of mime-types, but I have not yet investigated it deeply to verify it handles all cases.