Closed Bug 210724 Opened 21 years ago Closed 18 years ago

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

Categories

(Core :: DOM: Core & HTML, defect)

Product:
Core
Component:
DOM: Core & HTML
Platform:
PowerPC
macOS
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED

People

(Reporter: jason, Assigned: timeless)

References

(
URL
)

Details

(Keywords: fixed1.8.1, relnote)

Attachments

(3 files)

patch to remove plugin disabling v1.0
1.84 KB, patch
mikepinkerton
: superreview+
Details | Diff | Splinter Review
new nib
9.65 KB, application/octet-stream
Details
honor GetAllowPlugins
2.54 KB, patch
jst
: superreview+
dbaron
: approval1.8.1+
Details | Diff | Splinter Review 
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
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?
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
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.)
URL: http://www.macromedia.com/
What's going to be done?
This bug seems to be a duplicate of Bug 173125, please check.
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
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
also need a new nib file, coming up
Assignee: pinkerton → joshmoz
Attached file new nib — 
Removes UI, class outlets/targets, updates to 10.2+ format
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.
landed on trunk with Geoff's suggested changes.
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
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
Assignee: joshmoz → sfraser_bugs
Status: REOPENED → NEW
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: 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+

    
    

    
  
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

    
  
Status: ASSIGNED → RESOLVED
Closed: 20 years ago → 18 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?

        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+

    
    

    
  
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.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: