Closed Bug 277677 Opened 20 years ago Closed 10 years ago

Add a nsICategoryManager based plugin manager to mozilla

Categories

(SeaMonkey :: Preferences, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: Manuel.Spam, Unassigned)

References

Details

Attachments

(3 files, 1 obsolete file)

Firefox currently has an built in plugin manager (can be found via Tools ->
Options -> Downloads -> Plugins...). The relevant files are

http://lxr.mozilla.org/mozilla/source/browser/base/content/browser.js#785
http://lxr.mozilla.org/mozilla/source/browser/components/prefwindow/content/plugins.js
http://lxr.mozilla.org/mozilla/source/browser/components/prefwindow/content/plugins.xul

As the backend exists (nsICatogoryManager) in mozilla, I think it shouldn't be
too difficult to implement such a thing into mozilla 1.8.

Comments/Thoughts:

- I think the code for reading the property
"browser.download.pluginOverrideTypes" (browser.js) also should be added to the
main mail/news-file (msgMail3PaneWindow.js) in mozilla for the case the user has
chosen to start mail/news first when launching mozilla. Maybe a new
javascript-file should be added that both (browser and mail) get their code from
the same place and that, in case of an bug, only one file needs to be edited. In
case of a new javascript-file we also need a place for that file. To which place
could something like that be added?

- A place for the button that opens the window (plugins.xul) is needed in the
mozilla configuration system. A good place may be under Advanced -> Scripts &
Plug-ins.

Problems:

- The whole part about the property
"browser.download.pluginOverrideTypesNotHandled" should be left out as it
doesn't work. As soon as you open a second browser window (or open a mail window
if a browser window is open), the whole thing fails as all plugins in
"pluginOverrideTypes" get moved to "pluginOverrideTypesNotHandled" and you can't
longer reactivate deactivated plugins (they disappear). There are two ways to
fix that:
  - get sure that the code for reading the "pluginOverrideTypes"-property only
gets called once per session (maybe add an note in the hidden-dom-window).
  - Don't add the "pluginOverrideTypesNotHandled"-thing at all (any reason why
this can't be left out completely?).

Any other comments/suggestions?
As you want to do the visible changes (mainly?) in the prefs window, perhaps you
should select preferences as component?
Severity: normal → enhancement
Status: UNCONFIRMED → NEW
Ever confirmed: true
Attached image Screenshot of the current status (obsolete) —
Screenshot of current status of my development
Yes, I think you're right. The main thing is the possibility to change the
"preference" of the plugin enabled state.
Component: General → Preferences
The screenshot shows my final state. Extension *and* MIME-Type is shown and
also Plugins that don't register an Extension are shown on the list (the only
plugin I filter out is the default plugin which has "*" as MIME-Type. Noone
will know what this "*" means). It's possible to sort the list by clicking on
the col headers. Also the code that saves the settings to the preference and
updates the nsICategoryManager settings based on the user decision is done.
Still left is the code that needs to be executed if the browser or the mail
client starts.
Attachment #171112 - Attachment is obsolete: true
Note that the SeaMonkey ui is largely in maintenance mode.  So if people want
new features....
Keywords: helpwanted
....then what? Something I should know? I'm nearly finished with the needed
code. The next job seems to be a much harder nut to crack. I have to compile
mozilla to test if my patches don't make it impossible to build mozilla.
Currently I only get a few error messages and gmake doesn't run...

What do you mean with "the SeaMonkey ui is largely in maintenance mode". Is
there a bug about that? Can you please tell me the number?
I think Boris just overlooked that you are already doing the coding yourself.

Btw, if you attach your patch or send it to me I could try building Mozilla with
it. I do that every few days anyway, so we could iron out possible bugs before
the real review stage.
Keywords: helpwanted
(In reply to comment #7)
> I think Boris just overlooked that you are already doing the coding yourself.

Yes, maybe, but I'm interested about this "maintenance mode" means... Please
PLEASE no firefox-like UI for the Suite!!!

Does anybody have an bug number for that?

> Btw, if you attach your patch or send it to me I could try building Mozilla
> with it. I do that every few days anyway, so we could iron out possible bugs
> before the real review stage.

Thank you very much for your offer. I'll try again to build, but if I fail again
I'll submit my (unchecked) patches. Currently I do my debugging with "unzip" and
"zip". I think much faster than compiling for every debug run.
I've attached a first patch which should add the plugin-manager to mozilla.

@Peter Weilbacher: Could you please check this one?
Just built it from the trunk on my old Linux Redhat 7.3 system. Compiling works
(after manually patching jar.mn which has changed slightly) and your UI seems to
work mostly. But the backend does not seem to work. I deactivate anything about
flash on the plugins page and then go to
<http://www.cpf.gov.sg/cpf_info/trainingprogram/plugin.asp> and flash still
plays. But the same happens with Firefox 1.0 on my system so is probably normal.
about:plugins also still shows "Yes" in the enabled column.

Additionally, you seem to be getting/setting different info to what arrives in
about:plugins. There, Flash has two lines, one of them is
"application/futuresplash 	FutureSplash Player 	spl 	Yes"
while your UI does not show the SPL filename extension (only the MIME type), the
same happens with the Adobe AVG plugin. Before you also said that you wanted to
keep Java out of this, but now I see one line corresponding to each Java related
line in about:plugins? If this is intended I guess you should remove the setting
from the Advanced page.

Btw, if you don't want to change the help pages accordingly in this patch (the
section on "Advanced Preferences - Scripts & Plug-ins") there should be a
follow-up bug on that.
(In reply to comment #11)
> Just built it from the trunk on my old Linux Redhat 7.3 system. Compiling
> works (after manually patching jar.mn which has changed slightly) and your UI
> seems to work mostly. But the backend does not seem to work. I deactivate
> anything about flash on the plugins page and then go to
> <http://www.cpf.gov.sg/cpf_info/trainingprogram/plugin.asp> and flash still
> plays.

Uuups.... That's bad... I hoped this would block flash completely. It definetly
blocks the Acrobat Plugin, but I didn't test with flash so far. I've downloaded
the page you mentioned. I'll install flash on my testing machine and will do
some tests on that. Somewhere the flash plugin should have it's "link" in
nsICategoryManager (hopefully). I'll try to find out where.

> But the same happens with Firefox 1.0 on my system so is probably normal.

I don't use firefox normally. I only have it on my development system to debug
extensions, but it seems that even the current nightly of firefox doesn't have
another system for managing plugins (checked the file "browser.js" via lxr).

> about:plugins also still shows "Yes" in the enabled column.

The trick with manipulating "nsICategoryManager" doesn't change these settings.

> Additionally, you seem to be getting/setting different info to what arrives in
> about:plugins. There, Flash has two lines, one of them is
> "application/futuresplash 	FutureSplash Player 	spl 	Yes"
> while your UI does not show the SPL filename extension (only the MIME type),
> the same happens with the Adobe AVG plugin.

Yes. I query for MIME-Information and show the "primaryExtension" of the MIME
Type. This seems to be different to the display of about:plugins.

> Before you also said that you
> wanted to keep Java out of this, but now I see one line corresponding to each
> Java related line in about:plugins? If this is intended I guess you should
> remove the setting
> from the Advanced page.

I didn't touch about:plugins at all! I hope that my plugin manager doesn't show
any checkboxes that would allow to toggle Java (I have Java installed, but I
don't get any checkboxes).

> Btw, if you don't want to change the help pages accordingly in this patch (the
> section on "Advanced Preferences - Scripts & Plug-ins") there should be a
> follow-up bug on that.

OK, I think I'll have to file another bug later...
Attached image Screenshot on OS/2
> The trick with manipulating "nsICategoryManager" doesn't change 
> these settings.

That's a bit confusing then, but I guess on Firefox 1.0 it is the same? Should
I open a bug to request getting rid of that column?

> I didn't touch about:plugins at all! I hope that my plugin manager 
> doesn't show any checkboxes that would allow to toggle Java (I have 
> Java installed, but I don't get any checkboxes).

I tried the same now on OS/2: the Java plugin(s) appear in the list as on Linux
as does SWF. It may depend on the type of Java plugin, I used the Sun Java
plugin on Linux and the GoldenCode Java plugin on OS/2. 

If I switch off the SWF plugin I see that it gets listed in the
browser.download.pluginOverrideTypes pref but SWF movies continue to be loaded
in the webpage and play (on OS/2 there only is an old Flash version available,
so I used <http://scene.dem.ru/flash/flashed.php?menu>).

Additionally, there is a problem that the list thinks I click two lines below
the line where I really click, in the screenshot I just clicked on the tickmark
behind the line "application/x-java-bean;version 1.2". I tried some other
similarly looking listboxes (like the cookie manager) and there the correct
line is selected, but I am perfectly willing to accept that this is an OS/2
specific fault that we need to fix on OS/2 and would be grateful for a hint on
where I should start looking for this defect.

Btw, this appears in the JS console for every line that does not have an
extension:

Error: pluginInfo.primaryExtension has no properties
Source File: chrome://communicator/content/pref/pref-plugins.js
Line: 341

Do you see any possibility to somehow reference it as Tools->Plugin Manager
similar to the other managers? Always having to go through the prefs panel is
not very user friendly. I should probably have said that in the beginning, but
I only notice now after having gone through this a few dozen times what a
hassle this is...
(In reply to comment #13)
> That's a bit confusing then, but I guess on Firefox 1.0 it is the same? Should
> I open a bug to request getting rid of that column?

There is a difference between about:plugins. In about:plugins the plugins are
disabled if you install two plugins that want to handle the same MIME. The
plugin which gets the MIME first is enabled, then second disabled (AFAIK).

> I tried the same now on OS/2: the Java plugin(s) appear in the list as on 
> Linux as does SWF. It may depend on the type of Java plugin, I used the Sun
> Java plugin on Linux and the GoldenCode Java plugin on OS/2. 

Then I think Java has to be "blacklistet". For Java there is a better way to
disable. Or do you think it may be useful to keep the Java-MIME-Types configurable?

> If I switch off the SWF plugin I see that it gets listed in the
> browser.download.pluginOverrideTypes pref but SWF movies continue to be loaded
> in the webpage and play (on OS/2 there only is an old Flash version available,
> so I used <http://scene.dem.ru/flash/flashed.php?menu>).

Yes, they do. The plugin manager I'm currently trying to implement here only
stops plugins to "block downloads". Embeds are not blocked or modified. This
seems to be impossible to be done with nsICategoryManager. For example if you
disable the plugin for application/pdf then you'll be able to download PDF-Files
if you click on links to them. If the plugin is enabled you don't get asked if
you want to download and Acrobat Reader opens inside the browser window.

> Additionally, there is a problem that the list thinks I click two lines below
> the line where I really click, in the screenshot I just clicked on the
> tickmark
> behind the line "application/x-java-bean;version 1.2". I tried some other
> similarly looking listboxes (like the cookie manager) and there the correct
> line is selected, but I am perfectly willing to accept that this is an OS/2
> specific fault that we need to fix on OS/2 and would be grateful for a hint on
> where I should start looking for this defect.

It works in windows and linux... I don't know the reason why it fails with OS/2.
I don't have this OS and so I can't debug with it, but I know that OS/2 seems to
be one of the most difficult Operating systems for extension developers. I'm
project owner of PrefBar and I'm having problems with OS/2 very often.

> Btw, this appears in the JS console for every line that does not have an
> extension:
> 
> Error: pluginInfo.primaryExtension has no properties
> Source File: chrome://communicator/content/pref/pref-plugins.js
> Line: 341

Thanks for the hint. I'll have to look why this happens.

> Do you see any possibility to somehow reference it as Tools->Plugin Manager
> similar to the other managers? Always having to go through the prefs panel is
> not very user friendly. I should probably have said that in the beginning, but
> I only notice now after having gone through this a few dozen times what a
> hassle this is...

It should be hard to change this in this late stage... Why do you think you have
to toggle the settings very often?

Can you please attach a patch working in the latest nightly (you've mentioned
that you've changed something to get it running).
(In reply to comment #14)
> Then I think Java has to be "blacklistet". For Java there is a better way to
> disable. Or do you think it may be useful to keep the Java-MIME-Types
configurable?

No, if you find a way to not list any Java plugins that would be best.

> Embeds are not blocked or modified. This seems to be impossible to be done
with nsICategoryManager.

Ah, OK. That of course severely limits its usefulness...

> It should be hard to change this in this late stage... Why do you think you have
> to toggle the settings very often?

If it would block embeds then I would have used it much more often...
(In reply to comment #13)
> Additionally, there is a problem that the list thinks I click two lines below
> the line where I really click, in the screenshot I just clicked on the tickmark
> behind the line "application/x-java-bean;version 1.2". I tried some other
> similarly looking listboxes (like the cookie manager) and there the correct
> line is selected, but I am perfectly willing to accept that this is an OS/2
> specific fault that we need to fix on OS/2 and would be grateful for a hint 
> on where I should start looking for this defect.

I just found that these problems with this patch on OS/2 are vanished. 
Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.8b4) Gecko/20050726 SeaMonkey/1.0a
Unlike what I wrote above mouse clicks now select the correct line.
I think this one is resolved by the new "Helper Application" preferences panel, which allowes to change actions for mime types, which also covers plugins, right?
Cleaning up my bugs...

As far as I know, SeaMonkey has similar possibilities of plugin management as Firefox has. And I filed this one agains the old Mozilla suite --> WONTFIX.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: