Closed
Bug 539063
Opened 16 years ago
Closed 15 years ago
Implement a whitelist and blacklist for OOPP
Categories
(Core Graveyard :: Plug-ins, defect)
Core Graveyard
Plug-ins
Tracking
(status1.9.2 .4-fixed)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
status1.9.2 | --- | .4-fixed |
People
(Reporter: benjamin, Assigned: jaas)
References
Details
(Whiteboard: [fixed-lorentz])
Attachments
(1 file, 1 obsolete file)
2.40 KB,
patch
|
jaas
:
review+
|
Details | Diff | Splinter Review |
For OOPP, it's likely that we'll want to start out with a whitelist of plugins that we've tested work with OOPP. At some point we may want to flip it to a blacklist of plugins that are known not to work.
Josh, can you take this or find an owner? We probably want to do this with prefs, but I'm not sure whether we can reliably key off the plugin filename or some other marker.
Assignee: nobody → joshmoz
OS: Linux → All
Hardware: x86 → All
I've only tested this on Linux so far but it probably works fine on Windows.
You can specify per-library exceptions to whatever "dom.ipc.plugins.enabled" indicates by setting boolean prefs like "dom.ipc.plugins.enabled.libnpfoo.so".
Attachment #423592 -
Flags: review?(benjamin)
Reporter | ||
Comment 2•15 years ago
|
||
Josh, when reviewing this I thought of one issue and cleaned it up so we didn't need to use the localfile:
* because windows isn't case-sensitive, I've normalized the plugin name to lowercase before checking the pref
* Use string function RFindCharInSet instead of localfile->GetNativeLeafName because it's quicker and cleaner
Attachment #423854 -
Flags: review?(joshmoz)
Attachment #423592 -
Attachment is obsolete: true
Attachment #423592 -
Flags: review?(benjamin)
Attachment #423854 -
Flags: review?(joshmoz) → review+
Reporter | ||
Comment 3•15 years ago
|
||
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Comment 4•15 years ago
|
||
How exactly do I use this? I have a plugin that doesn't play well with OOPP and I'd like to blacklist it.
Thanks
Reporter | ||
Comment 5•15 years ago
|
||
Starting with tomorrow's nightly:
* find the file name of your plugin by looking in about:plugins
* go to about:config
* create a new boolean pref "dom.ipc.plugins.enabled.<filename>" with value "false"
BTW, what plugin are you blacklisting?
Comment 6•15 years ago
|
||
Foxit Reader, the latest version.
Comment 7•15 years ago
|
||
looks like Bug 542792
![]() |
||
Comment 8•15 years ago
|
||
Would it be possible to specify a leafname without the extension so for example
dom.ipc.plugins.enabled.npswf32
will allow NPSWF32.dll NPSWF32.so NPSWF32.dylib etc.
Comment 9•15 years ago
|
||
The Flash plugin is:
npswf32.dll on Windows
libflashplayer.so on Linux
"Flash Player.plugin" on OS X.
I don't see how that would help anything.
Reporter | ||
Comment 10•15 years ago
|
||
Whiteboard: [fixed-lorentz]
Comment 11•15 years ago
|
||
Blanket approval for Lorentz merge to mozilla-1.9.2
a=beltzner for 1.9.2.4 - please make sure to mark status1.9.2:.4-fixed
Reporter | ||
Comment 12•15 years ago
|
||
Merged into 1.9.2 at http://hg.mozilla.org/releases/mozilla-1.9.2/rev/84ba4d805430
status1.9.2:
--- → .4-fixed
Comment 13•15 years ago
|
||
While this still remains a whitelist, what mechanism is in place to add plugins to the whitelist by default in newer releases?
If no bug about that exists, should one be filed based on stats gained from http://www.mozilla.com/en-US/plugincheck/ showing a rank of the most installed plugins?
Updated•3 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•