194986 - Disabled (Acrobat) plugin(s?) still enabled.

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Plug-ins, defect)

Description

[James Nord]

I have previously disabled the Acrobat plugin by setting the desired min version
of the plugin to 10.0, however in 1.3b this no longer works.

Steps to reproduce

1) quit mozilla
2) install acrobat / acrobat reader
3) edit pref.jas and add the following line 'user_pref("plugin.scan.Acrobat",
"10.0");'
4) start mozilla
5) open a link to a PDF file in mozilla

Actual results
PDF displays inside mozilla

Expected results
PDF is saved and/or opened in Acrobat


From about:plugins
Adobe Acrobat
    File name: nppdf32.dll
    Adobe Acrobat Plug-In Version 5.00 for Netscape
MIME Type 	Description 	Suffixes 	Enabled
application/pdf 	Acrobat 	pdf 	Yes

From Helper applications,
Application/pdf -> Open these files using the default application

(System default is Acrobat)

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.3b) Gecko/20030210

Comment 1

[WADA:World Anti-bad-Duping Agency]

(Q1) Are there "nppdf32.dll" in Mozilla's Plugins directry?
(Q2) Did you enable "Quick Launch"?
(Q3) Does "about:config" in URL bar display "plugin.scan.Acrobat"="10.0" after
restart?
(Q4) How about "plugin.scan.Acrobat"="9.0" case?
     Mozilla maybe misunderstood "10.0" as "1". 
(Q5) Isn't it a same problem as Bug 147309 ?
     Ignoring Adobe Acrobat reader settings for "Display PDF in Browser"

Comment 2

[WADA:World Anti-bad-Duping Agency]

Comfirmed on 2003122108-trunk/Win-Me.
(James Nord, sorry for late comfirm)

(1) Acrobat Reader 6.0 and Windows Media Player 9 are installed.
(2) Only npnull32.dll exists in Mozilla's Plugins directry
    (Zip version of Mozilla is used).
(3) I deleted "pluginreg.dat" in Mozilla directry before restart.
    ( "C:\WINDOWS\Application Data\Mozilla\pluginreg.dat" on MS Win-Me )
(4) user.js in profile contains next 2 lines.
    user_pref("plugin.scan.Acrobat", "9.0");
    user_pref("plugin.scan.WindowsMediaPlayer", "9.9");
(5) about:config displayed plugin.scan.xxx settings  as user.js specifies.
    plugin.scan.Acrobat = 9.0 (string data)
    plugin.scan.WindowsMediaPlayer = 9.9 (string data)
 
Even though abobe, about:plugins displayed plugins of Acrobat Reader 6.0 and
Windows Media Player 9.
No difference was observed in about:plugins display when version number for WMP
9 is changed to "9.9", "10.0", and "A.A".

Comment 3

[Dan Mellem]

I have experienced this as well and it has been confirmed by WADA as well.
Confirming bug.

Comment 4

[WADA:World Anti-bad-Duping Agency]

I've found description on how to disable plugin search.
 ( http://plugindoc.mozdev.org/faqs/acroread.html#win-scan )
We probably have to comment out pref("plugin.scan.Acrobat", "X.0"); in
\greprefs\all.js or \default\pref\winprefs.js in order to disable plugin search.
Is this intentional design to avoid accidental disabling of plug in search by users?

By the way, http://plugindoc.mozdev.org/faqs/acroread.html#win-ar6-speed also
describes how to escape from terrible slowness of Adobe Reader 6.0.
Thanks a lot to Plugin Doc project.

Comment 5

[jwq]

Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.3) Gecko/20040910

 I just stumbled on this bug, or something like it on the Mac. A recent
Quicktime update, Quicktime 6.5.2, installs a new version of the Quicktime
plugin which can display PDF files in the browser. Mozilla builds pluginreg.dat
when it sees the new plugin, using (presumably) the default MIME settings for
the Quicktime plugin which are stored in
~/Library/Preferences/com.apple.quicktime.plugin.preferences.plist. The user may
change these settings via System Preferences -> Quicktime -> Plugin -> MIME
Settings... which will update the plist file. I wanted to disable PDF display in
Mozilla and switched off the setting in System Preferences. Unfortunately,
Mozilla doesn't see that the plist settings have changed and won't update
pluginreg.dat. Therefore, Mozilla continued to display PDF in the browser even
though the Quicktime plugin preference was disabled.

Workaround: it appears that Mozilla will rebuild pluginreg.dat if the
modification date of a plugin is after that of pluginreg.dat. Executing 'touch
/Library/Internet\ Plug-Ins/QuickTime\ Plugin.plugin/' in the terminal and
reloading about:plugins will force a rebuild of pluginreg.dat and the latest
Quicktime MIME settings from the plist file will be used.

Alternate Workaround: delete pluginreg.dat to force the rebuild.

Related Bug: Bug 236201.

Comment 6

[Dan Mellem]

On Windows, see also bug 159445. This creates a new preference
  plugin.scan.plid.all = true

If you set this to false, it won't try to find plugins by the registry (but this
is all or nothing). But, this change was made on 5/27/03 which predates this
bug. The only changes between when "plugin.scan.Acrobat" was added (4/30/02),
and when this bug was filed, are in bug 133282 (5/2/02), bug 178643 (1/8/03),
and bug 197924 (3/24/03), assuming the problem is in nsPluginDirServiceProvider.cpp.

However, this seems to work again, at least for me. If I set
"plugin.scan.Acrobat" to 999 (w/Acrobat 5.0 installed) then the plugin doesn't load.

If you set "plugin.expose_full_path" to true then you can see which plugin it's
loading.

Comment 7

[WADA:World Anti-bad-Duping Agency]

For PDF, if "Disabling plugin for PDF" is "Disabling display PDF in Browser",
Adobe Reader 7.0 resolved the problem.
See Bug 147309 Comment #31.

Comment 8

[WADA:World Anti-bad-Duping Agency]

DUP of Bug 147309, isn't it?

Comment 9

[James Nord]

Re comment#7

No this is same symtom different cause.

If the "Diable display PDF in browser" option on Acrobat removes the plugin from c:\progarm files\acrobat\blah then this is not solving this bug.

Users may not have access to delete that file so we need a per user way of disabling the plugin - ie don't let firefox load it.

Comment 10

[WADA:World Anti-bad-Duping Agency]

(In reply to comment #9)
> No this is same symtom different cause.

I see. This bug is mainly for problem of "plugin scan can not be disabled" and not for PDF only, and Bug 147309 is for phenomenon of "Disabling of Display PDF in Broweser won't work if plugin scan is enabled" only and for PDF only.
Root cause is this bug, and Bug 147309 was worked around by change in Adobe Reader  7.0 or later when PDF on MS Win case.
Setting dependency. 

Comment 11

[Winfried]

A simple message under Options->Applications would help: These settings are not always effective, you might want to disable the associated plugin under Tools -> Add-ons -> Plugins.

I noticed that for 3GPP Content (audio/amr), I can't even set the option to "Always ask". I will be reset to either "Save" or "Quicktime".

Comment 12

[Benjamin Smedberg]

non-Flash plugins are dead.