Closed
Bug 189378
Opened 22 years ago
Closed 15 years ago
Pref to disable plugins in browser
Categories
(Core Graveyard :: Plug-ins, defect)
Core Graveyard
Plug-ins
Tracking
(blocking2.0 -, status1.9.2 .1-fixed, fennec1.0+)
RESOLVED
FIXED
mozilla1.9.3a1
People
(Reporter: doronr, Assigned: Gavin)
References
Details
Attachments
(1 file, 2 obsolete files)
(deleted),
patch
|
jaas
:
review+
|
Details | Diff | Splinter Review |
As per our meeting, we should have a pref to turn off plugins in the browser (as
we do for mailnews). We can put it in the UI in my script and plugins panel.
Comment 1•22 years ago
|
||
Should this include a way for the user to start an individual plug-in object?
Say I'm on dial-up and browsing with plug-ins turned off. If I see a Flash
movie I want to start, I should be able to click the element to turn on the
Flash plug-in just for that element.
Comment 2•22 years ago
|
||
*** Bug 200466 has been marked as a duplicate of this bug. ***
Comment 3•22 years ago
|
||
After reading Doug's example of how "WebLock" uses nsIContentPolicy and fixing
bug 90256 so full-page plugins use the embedded code path which already checks
content policy, I think perhaps a "plugin manager" for the blocking of certain
plugins on certain urls could be created.
If someone who's got more time to work on the front end could try to implement
nsIContentPolicy in Javascript or C++ and register with "content-policy" in the
catagory manager. Example can be taken from embedding's nsWebBrowserModule.cpp
and nsWebBrowserContentPolicy.cpp which currently do a simple boolean check of
the allowPlugins attribute on the docshell which makes the disabling work in
composer and mail/news.
I think per site/plugin policies for plugins is a different bug. This bug is
about adding a boolean pref to enable/disable all plugins in content area. Few
lines of code if you know where to place it.
This may be doable with Content Policy (perhaps even in a way that could easily
extend to per-site permissions in addition to global settings).
Comment 6•19 years ago
|
||
(In reply to comment #4)
> I think per site/plugin policies for plugins is a different bug. This bug is
> about adding a boolean pref to enable/disable all plugins in content area. Few
> lines of code if you know where to place it.
I think each plugin should be handled by itself. For example, I have Windows
XP, and do not want to use windows media player for streaming, since MPlayer is
my preferred program, so I would like to disable the windows media plugin, but I
do want to have Flash enabled. Others may want just the opposite. If the user
is to have control of his/her browsing experience, case by case plugin
management is a must. If a streaming media plugin is disabled, I would like to
see an option in Firefox to call a specified program with argument options to
open the streaming media i.e. for mplayer "PathtoMplayer"mplayer
http_proxy://myproxy.com:8080/%1 (%1 can be replaced by whatever variable works
best for the address of the stream). The second feature that I listed can
mostly be accomplished via the MediaConnectivity extention (except it does not
handle the argument options), but I think this should be a browser feature,
given that many media players do not have plugins for streaming media.
Comment 7•19 years ago
|
||
*** Bug 313433 has been marked as a duplicate of this bug. ***
Comment 8•18 years ago
|
||
I dont think it should be a pref. it should be a command line option like "-noplugin" AND even more important an option in the safe mode dialog
Updated•18 years ago
|
QA Contact: shrir → plugins
Assignee | ||
Updated•16 years ago
|
Assignee: peterlubczynski-bugs → nobody
OS: Windows 2000 → All
Hardware: x86 → All
Assignee | ||
Comment 9•15 years ago
|
||
This seems to work OK, but I'm not sure the "plugin unloading" part is kosher. I wanted to make the pref live since Fennec wants to expose this in the front-end, and a live pref is better for that.
Updated•15 years ago
|
blocking2.0: --- → ?
Assignee | ||
Comment 10•15 years ago
|
||
Attachment #404919 -
Attachment is obsolete: true
Attachment #423602 -
Flags: review?(joshmoz)
Comment 11•15 years ago
|
||
Comment on attachment 423602 [details] [diff] [review]
non-live version
I'd prefer to have the pref and its associated nsPluginHost member variable refer to the exceptional state, which is having all plugins disabled. If you make the pref "plugins.disabled" and the member variable "mPluginsDisabled" you can also kill off:
+ mLoadPlugins(PR_TRUE)
because of the zeroing new.
Aside from flipping that around this looks fine.
Assignee | ||
Comment 12•15 years ago
|
||
Assignee: nobody → gavin.sharp
Attachment #423602 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #423674 -
Flags: review?(joshmoz)
Attachment #423602 -
Flags: review?(joshmoz)
Attachment #423674 -
Flags: review?(joshmoz) → review+
Updated•15 years ago
|
tracking-fennec: --- → 1.0+
Assignee | ||
Updated•15 years ago
|
Attachment #423674 -
Flags: approval1.9.2.1?
Assignee | ||
Comment 13•15 years ago
|
||
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a1
Assignee | ||
Comment 14•15 years ago
|
||
got a=stuart on IRC
https://hg.mozilla.org/releases/mozilla-1.9.2/rev/3106e75962d3
status1.9.2:
--- → .1-fixed
Updated•15 years ago
|
Attachment #423674 -
Flags: approval1.9.2.2?
Updated•14 years ago
|
blocking2.0: ? → -
Updated•2 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•