docShell.allowPlugins not honored for direct links




12 years ago
6 years ago


(Reporter: mikeperry.unused, Assigned: johns)



Firefox Tracking Flags

(Not tracked)



(3 attachments)



12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070914 Firefox/
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv: Gecko/20070914 Firefox/

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 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...


12 years ago
Summary: docShell.allowPlugins not enforced for direct links → docShell.allowPlugins not honored for direct links


11 years ago
Keywords: privacy


11 years ago
Ever confirmed: true
Created attachment 310371 [details]
Test extension sets allowPlugins = false
Created attachment 310372 [details]
Flash content for following testcase
Created attachment 310373 [details]
Testcase for use with test extension
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.

Comment 5

11 years ago
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.


9 years ago
Flags: blocking1.9.0.19?
Flags: blocking1.9.0.19?

Comment 6

8 years ago
The Tor Project / Electronic Frontier Foundation is paying to have this bug

"If you know C++ and/or Firefox internals, we should be able to pay you for
your time to address these issues and shepherd the relevant patches through
Mozilla's review process."


Comment 7

6 years ago
Does this issue still occur?

The full page plugin cleanups in bug 767638 should've removed the last bits of "full page" plugins being a special case, and I wasn't able to reproduce this locally.
Assignee: nobody → jschoenick
Component: Security → Plug-ins
Flags: needinfo?(mikeperry.unused)
OS: Windows XP → All
Product: Firefox → Core
Hardware: x86 → All

Comment 8

6 years ago
Was likely fixed by bug 767638
Last Resolved: 6 years ago
Flags: needinfo?(mikeperry.unused)
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.