Plugins disabled in preferences but still visible from JavaScript navigator.plugins and navigator.mimeTypes arrays

VERIFIED FIXED

Status

()

Core
DOM: Core & HTML
VERIFIED FIXED
15 years ago
12 years ago

People

(Reporter: Jason Patterson, Assigned: timeless)

Tracking

({fixed1.8.1, relnote})

Trunk
PowerPC
Mac OS X
fixed1.8.1, relnote
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(3 attachments)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030306 Camino/0.7
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20030306 Camino/0.7

If the user disables plugins in the Camino preferences this should cause the
JavaScript navigator.plugins array to become empty, and should remove the
relevant entries from the navigator.mimeTypes array (or at least set their
enabledPlugin member to null), so that plugin detection mechanisms correctly
detect that a plugin is not available and use a static image (or whatever)
instead. This problem doesn't occur in Mozilla/Pheonix etc simply because the
user can't blanket-disable plugins through a single preference checkbox like
they can in Camino.

Reproducible: Always

Steps to Reproduce:
1. Create a simple test page containing a script, such as:
   <HTML><BODY><SCRIPT LANGUAGE="JavaScript"><!--
   if (navigator.mimeTypes && navigator.mimeTypes["video/quicktime"] &&
       navigator.mimeTypes["video/quicktime"].enabledPlugin) {
           document.write("QuickTime plug-in = " +
                   navigator.mimeTypes["video/quicktime"].enabledPlugin.name);
   } else {
           document.write("QuickTime plug-in not available");
   }
   // --></SCRIPT></BODY></HTML>
2. View the page in Camino with plugins on (normal state).
3. Turn plugins off in the Camino preferences.
4. Quit and re-launch Camino.
5. View the page in Camino with plugins off.
6. Notice that the plugin is still detected, which is wrong.
Actual Results:  
When you view the page in Camino with plugins on you get a message like
"QuickTime plug-in = QuickTime Plug-in 6.3", which is correct. But when you view
the page in Camino with plugins off, you *STILL* get a message like "QuickTime
plug-in = QuickTime Plug-in 6.3" even though plugins are actually disabled and
an EMBED tag would produce a blank area on the page.

Expected Results:  
When plugins are disabled the navigator.plugins array should be empty and the
enabledPlugin member of each mimeType object should be null. If that were the
case, the page would produce "QuickTime plug-in not available" when plugins are
disabled, which would be correct.

As an aside, the preference pane which allows plugins to be disabled should
really mention that this setting only takes effect after a quit and re-launch.
what happens in mozilla?
Assignee: saari → pinkerton
(Reporter)

Comment 2

15 years ago
This problem doesn't occur in Mozilla simply because the user can't
blanket-disable plugins through a single preference checkbox like they can in
Camino. So in Mozilla plugins are always "on".
yikes. when did that happen?
(Reporter)

Comment 4

15 years ago
When did what happen? The ability to disable plugins? As far as I know, Mozilla
has never had the ability to disable plugins through the preferences. Even
Netscape 3.x/4.x didn't allow this, although the Mac version of Netscape 3.x/4.x
did allow individual plugins to be disabled via the helper applications preferences.

IE/Mac has had the ability to disable plugins for a while, and it works properly
(removing the navigator.plugins entries, setting enabledPlugin to null etc), as
does OmniWeb, but some other browsers that allow the user to disable plugins
(Safari, Opera & iCab) also get this wrong and don't clear the navigator.plugins
array etc.

It seems pretty clear that it's just an oversight - the checkbox is controlling
whether or not the code which actually initializes and runs plugins gets
executed, but doesn't think about the visibility of the plugins from JavaScript.
if the pref doesn't work, we should remove it from the UI
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
Target Milestone: --- → Camino0.8

Comment 6

15 years ago
I'd hate to see this pref removed instead of the script oversight (if that's
truely the codepath here) getting fixed.

But something needs to be done here because right now it looks like with plugins
off you're getting stuck in the middle and stranded without content on some
sites (http://www.macromedia.com/) as JS checks the plugins array and thinks
flash is active and tries to feed you the Flash movie instead of the alternate
content (img, redirect, etc.)

Comment 7

15 years ago
What's going to be done?

Comment 8

15 years ago
This bug seems to be a duplicate of Bug 173125, please check.
(Reporter)

Comment 9

15 years ago
Well, it’s not exactly a duplicate, but it’s certainly related. Bug 173125 is
talking about the issue of whether plugins are loaded or not at launch, which is
somewhat independent of whether they are currently turned on or off at any point
in time.

So, there are really 3 ways to solve this...

1. Take away the GUI checkbox. This is the easiest, and is probably fine for 99%
of users, who never turn off plugins anyway. This would solve both bugs 210724
and 173125, but only in the sense of removing the feature altogether.

2. Make the GUI checkbox work correctly but apply only at the next launch. It
already only applies at the next launch anyway, so you would just need to 1) add
a note on the GUI to say that, and 2) add a check in the plugin loading code to
skip it if the preference says plugins are off, which should have the side
effect of not building up the navigator.plugins JavaScript array etc. This would
solve both bugs 210724 and 173125 properly.

3. Make the GUI checkbox work correctly and apply immediately. This would be the
ideal solution for end-users, since they could then turn plugins on and off at
will without quitting and re-launching. But whether that’s really a useful
feature or not is debatable, and it would also require the most work, since
neither the plugin activation code nor the JavaScript navigator.plugins stuff
does this correctly now. And of course this would only solve bug 210724, not
173125 (because plugins would always have to be loaded at launch so they can be
used if the user has plugins turned on at any given moment).
i'll probably do option 1

Comment 11

15 years ago
eek... deleting and reinstalling plugins for web site testing is a pain in the
ass & with a central plugin directory on OS X this change makes it hard for
those general users who don't want flash in Camino but don't mind it elsewhere.
(or have it disabled everywhere - all other browsers have this pref - but not
removed from their system entirely)

Now I'm not going to fight you on your decision I'd rather have it out then
totatlly broken as it is now (I'm most concerned with the visiblity from the
javascript side), but I do expect you'll hear it from somewhere.
Keywords: relnote
Target Milestone: Camino0.8 → Camino0.9

Comment 12

14 years ago
Created attachment 166432 [details] [diff] [review]
patch to remove plugin disabling v1.0

also need a new nib file, coming up
Assignee: pinkerton → joshmoz

Comment 13

14 years ago
Created attachment 166433 [details]
new nib

Removes UI, class outlets/targets, updates to 10.2+ format

Comment 14

14 years ago
Comment on attachment 166432 [details] [diff] [review]
patch to remove plugin disabling v1.0

this is a simple one
Attachment #166432 - Flags: superreview?(pinkerton)
Attachment #166432 - Flags: review?(me)
Comment on attachment 166432 [details] [diff] [review]
patch to remove plugin disabling v1.0

sr=pink, though i haven't tried it. have the reviewer ensure the nib works as
intended.
Attachment #166432 - Flags: superreview?(pinkerton) → superreview+
I haven't tested yet, but there's a problem with this patch.

I tend to browse with plugins disabled, and re-enable them when I encounter a
problem because of it. If I install a build with this patch, plugins will still
be disabled and I'll have no easy way to re-enable them when I encounter a problem.

To fix this, I'd suggest making the following additional changes:

1. Change BrowserWrapper.mm so that it enables/disables plugins based on
"camino.enable_plugins" instead of "chimera.enable_plugins".
http://lxr.mozilla.org/mozilla/source/camino/src/browser/BrowserWrapper.mm#119

2. Change all-camino.js to have
pref("camino.enable_plugins", true);

This will cause plugins to be enabled by default for a new build without the GUI
option to enable/disable but still let folks who need the capability (even if it
doesn't work perfectly) add a line to user.js to disable them if needed.
Attachment #166432 - Flags: review?(me) → review-
i agree with geoff.

Comment 18

14 years ago
landed on trunk with Geoff's suggested changes.
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago
Resolution: --- → FIXED

Comment 19

13 years ago
jst: what's the deal with disabling plugins via
nsIWebBrowserSetup::SETUP_ALLOW_PLUGINS still keeping navigator.plugins around?

Reopening because the hidden pref is still there and broken.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Target Milestone: Camino0.9 → Camino1.1

Updated

13 years ago
Assignee: joshmoz → sfraser_bugs
Status: REOPENED → NEW

Comment 20

13 years ago
jst: ping?
So really, what should happen is that http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsPluginArray.cpp#263 should just bail out early if plugins are disabled for that docshell, right?

Note that handling dynamic changes to this setting on the docshell would be pretty hard from here... do we care?

Simon, Mike, for 1.9 I'd sort of like to go through all of our nsIWebBrowserSetup stuff and fix the (numerous) bugs we have with it.... at least if we can find the time to do it.  :(
(Assignee)

Comment 22

12 years ago
Created attachment 215666 [details] [diff] [review]
honor GetAllowPlugins
Assignee: sfraser_bugs → timeless
Status: NEW → ASSIGNED
Attachment #215666 - Flags: superreview?(jst)
Attachment #215666 - Flags: review?(jst)
Comment on attachment 215666 [details] [diff] [review]
honor GetAllowPlugins

r+sr=jst
Attachment #215666 - Flags: superreview?(jst)
Attachment #215666 - Flags: superreview+
Attachment #215666 - Flags: review?(jst)
Attachment #215666 - Flags: review+
(Assignee)

Comment 24

12 years ago
Comment on attachment 215666 [details] [diff] [review]
honor GetAllowPlugins

mozilla/dom/src/base/nsPluginArray.cpp 	1.30
mozilla/dom/src/base/nsPluginArray.h 	1.18
Attachment #215666 - Attachment is obsolete: true
(Assignee)

Updated

12 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 14 years ago12 years ago
Component: General → DOM: Level 0
Flags: review-
Flags: review+
Product: Camino → Core
QA Contact: winnie → alqahira
Resolution: --- → FIXED
Target Milestone: Camino1.1 → ---
Version: unspecified → Trunk
Verified with Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20060321 Camino/1.2+

After viewing about:plugins, disabling plugins via the hidden pref via about:config and then re-opening about:plugins causes about:plugins to report no plugins are installed.

I suppose this means we can re-enable the UI in Camino now ;)
Status: RESOLVED → VERIFIED
Comment on attachment 215666 [details] [diff] [review]
honor GetAllowPlugins

timeless said this was a pretty trivial fix, so we'd like to get this on 1.8.1 so we can re-enable our UI in Camino 1.x (now bug 331293) and at the very least make the currently-hidden pref work correctly there, too.
Attachment #215666 - Flags: approval-branch-1.8.1?(jst)
Comment on attachment 215666 [details] [diff] [review]
honor GetAllowPlugins

Why is this patch obsolete?
Comment on attachment 215666 [details] [diff] [review]
honor GetAllowPlugins

jst, what are the prospects of getting this on the branch?  We'd really like to restore the disable plugins UI in Camino that we had to rip out orginally (when this bug was in the Camino product).

timeless, correct me if I'm wrong, but this patch is not "obsolete" per se but just "checked in", right?

Updated

12 years ago
Attachment #215666 - Flags: approval-branch-1.8.1?(jst) → approval1.8.1?
Attachment #215666 - Attachment is obsolete: false
Attachment #215666 - Flags: approval1.8.1? → approval1.8.1+
(Assignee)

Comment 29

12 years ago
Comment on attachment 215666 [details] [diff] [review]
honor GetAllowPlugins

MOZILLA_1_8_BRANCH:
mozilla/dom/src/base/nsPluginArray.cpp 	1.29.12.1
mozilla/dom/src/base/nsPluginArray.h 	1.17.18.1
Keywords: fixed1.8.1
You need to log in before you can comment on or make changes to this bug.