391820 - Addons manager breaks without MOZ_PLUGINS

Status: RESOLVED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Thomas Schade]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007081005 Minefield/3.0a8pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007080807 Thunderbird/3.0a1pre ID:2007081004

After opening 'Tools - Add ons' the extension manager does not show any installed extensions, themes or plugins in the several tabs.

Error Console shows:
Error: uncaught exception: [Exception... "Component returned failure code: 0x80570018 (NS_ERROR_XPC_BAD_IID) [nsIJSCID.getService]"  nsresult: "0x80570018 (NS_ERROR_XPC_BAD_IID)"  location: "JS frame :: chrome://mozapps/content/extensions/extensions.js :: initPluginsDS :: line 482"  data: no]
--------------------------------------------------------------------------------
Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIObserverService.removeObserver]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://mozapps/content/extensions/extensions.js :: Shutdown :: line 669"  data: no]

Reproducible: Always

Steps to Reproduce:
1. Just open extension manager with at least one extension installed.
2.
3.
Actual Results:  
EM does not display the extension.

Comment 1

[Thomas Schade]

Might be related to https://bugzilla.mozilla.org/show_bug.cgi?id=339056

Comment 2

[Nir]

Confirming .[version 3.0a1pre (2007081104) (Linux version )]

Comment 3

[Nir]

In Linux version problem is worse . On start it shows empty add-on window , with extension , themes, language , plugins , update tabs . If 'skip' button is clicked or 'X' button is clicked only then Thunderbird window is available. 

Comment 4

[Nir]

Attachment: Screen shot of the empty add-ons window

Comment 5

[Nir]

Thomas, I think you should change "OS" to "All"

Comment 6

[Joe Sabash [:JoeS1]]

Confirming regression range:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007080912 Thunderbird/3.0a1pre ID:2007080912  Works fine.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a8pre) Gecko/2007081004 Thunderbird/3.0a1pre ID:2007081004  Shows empty add-ons window.

Looks like bug 339056 for sure

Comment 7

[Benjamin Smedberg]

If this only happens when plugins are disabled, can we just WONTFIX this bug (or add an appropriate configure check so that Firefox can't be built with that option)?

Comment 8

[Thomas Schade]

(In reply to comment #7)
> If this only happens when plugins are disabled,

I'm sorry but this happens with every extension, independent whether they're disabled or enabled. With 5 extensions installed, 4 of them enabled, EM in Thunderbird doesn't show any of them.

For plugins I don't know, I don't have any installed in Thunderbird.

Comment 9

[Benjamin Smedberg]

I am talking about the --disable-plugins configure flag. Are you testing with official nightly builds or self-builds? If self-builds, are you using any configure (mozconfig ac_add_options) flags?

Comment 10

[Thomas Schade]

Oh, I see. I'm using official nightly builds, received through automatic update channel.

Comment 11

[Joe Sabash [:JoeS1]]

The bug has nothing to do with the fact that plugins a dosabled.
I have been using plugins in trunk builds of TB for years.
As a matter of fact, I hoped for more flexibility when I saw the new plugins tab.

Comment 12

[Joe Sabash [:JoeS1]]

Additionally:
The official trunk builds have had plugins enabled forever.

Let's not talk about throughing away another wanted feature as a matter of convenience.
  

Comment 13

[Robert Strong (they/them - no direct email)]

Attachment: patch - adds a try catch

I should have caught this in the review. :(

Comment 14

[Michael Wu [:mwu]]

(In reply to comment #13)
> Created an attachment (id=276303) [details]
> patch - adds a try catch
> 
> I should have caught this in the review. :(
> 
Can we just preprocess this out entirely? It turns out that thunderbird doesn't have plugins.xpt in packages-static, which I suspect prevents the plugin listing code from working properly.

Comment 15

[Robert Strong (they/them - no direct email)]

I considered that but then it wouldn't handle XULRunner app's where we don't know whether it is or isn't available.

Comment 16

[Robert Strong (they/them - no direct email)]

Actually we could... Benjamin, do you have a preference?

Comment 17

[Joe Sabash [:JoeS1]]

(In reply to comment #14)
> (In reply to comment #13)
> > Created an attachment (id=276303) [details] [details]
> > patch - adds a try catch
> > 
> > I should have caught this in the review. :(
> > 
> Can we just preprocess this out entirely? It turns out that thunderbird doesn't
> have plugins.xpt in packages-static, which I suspect prevents the plugin
> listing code from working properly.
> 

I guess you are not listening.
Thunderbird trunk does package plugins.xpt

Comment 18

[Robert Strong (they/them - no direct email)]

Joe... right, and by preprocessing the code using an #ifdef MOZ_PLUGINS as Michael suggested the code in the EM that requires Thunderbird to support plugins won't be called.

Comment 19

[Michael Wu [:mwu]]

(In reply to comment #17)
> I guess you are not listening.
> Thunderbird trunk does package plugins.xpt
> 
Oh? Where is it? I don't see it in thunderbird/components.

Comment 20

[Joe Sabash [:JoeS1]]

(In reply to comment #14)
> (In reply to comment #13)
> > Created an attachment (id=276303) [details] [details]
> > patch - adds a try catch
> > 
> > I should have caught this in the review. :(
> > 
> Can we just preprocess this out entirely? It turns out that thunderbird doesn't
> have plugins.xpt in packages-static, which I suspect prevents the plugin
> listing code from working properly.
> 

I guess you are not listening.
Thunderbird trunk does package plugins.xpt

Comment 21

[Joe Sabash [:JoeS1]]

Ok I'll just make this one more comment and stop spamming this bug.
I'm using a trunk build that has plugins.xpt built into it.
The changes that brought about this bug caused a blank EM window.
I don't see how pre-processing with an ifdef will solve that.
Maybe for a build that does not have plugins.xpt
Why not fix it for TB builds that do have the xpt and those builds are the current trunk builds.

Comment 22

[Michael Wu [:mwu]]

(In reply to comment #21)
> Ok I'll just make this one more comment and stop spamming this bug.
> I'm using a trunk build that has plugins.xpt built into it.
If you really were using a build with plugins.xpt, you wouldn't have this problem. Neither windows or linux nightly thunderbird builds have plugins.xpt - which is a Thunderbird problem. It has MOZ_PLUGINS turned on without packaging plugins.xpt. There is also another issue of this code needing to work when plugins are not compiled in, which is what preprocessing lines out would fix.

Comment 23

[Robert Strong (they/them - no direct email)]

Comment on attachment 276303 [details] [diff] [review]
patch - adds a try catch

Hey Michael, neither of us got the memo about plugin support being enabled on trunk for Thunderbird... I believe the problem is that when they added it they didn't add plugin.xpt to packages-static

Comment 24

[Robert Strong (they/them - no direct email)]

Filed bug 391886 for the Thunderbird specific issue

Comment 25

[Robert Strong (they/them - no direct email)]

Reassigning - Michael has a patch just about done using #ifdef MOZ_PLUGINS.

Comment 26

[Benjamin Smedberg]

So I'm still confused about this bug. Is it thunderbird-only because we're not packaging plugins.xpt, or Firefox with --disable-plugins, or something else?

I would prefer to not support the MOZ_PLUGINS (--disable-plugins) flag for toolkit... it's only meant for small-device embedders who aren't going to be using the EM anyway.

Comment 27

[Joe Sabash [:JoeS1]]

(In reply to comment #26)
> So I'm still confused about this bug. Is it thunderbird-only because we're not
> packaging plugins.xpt, or Firefox with --disable-plugins, or something else?
> 
> I would prefer to not support the MOZ_PLUGINS (--disable-plugins) flag for
> toolkit... it's only meant for small-device embedders who aren't going to be
> using the EM anyway.
> 
If you view bug activity, you will see that the bug was basically hi-jacked.
Poor bug etiquette IMO
Mscott seems to be unavailable at the moment for TB input.

Comment 28

[Dave Townsend [:mossop]]

The bug was moved to Firefox because that is where the extension manager component resides at the moment. This is not hijacking it but moving it to the component where those interested will see it.

Comment 29

[Joe Sabash [:JoeS1]]

Right, and if the result fixed the original bug in TB, that would be fine.
But right now nothing connects the original problem reported for TB to the suggested fix in the spinoff bug except an sr request in that bug (which shows the solution but not the original problem.)
Blocking and depends on flags would have preserved that connection.

Comment 30

[Michael Wu [:mwu]]

Attachment: Check MOZ_PLUGINS

Comment 31

[Robert Strong (they/them - no direct email)]

Benjamin, what is the use case where using the MOZ_PLUGINS flag is going to cause problem if it is used in toolkit? We can always try catch it but I'd like to know why it is an issue.

Comment 32

[Robert Strong (they/them - no direct email)]

Also, calendar still doesn't use plugins iirc.
http://lxr.mozilla.org/seamonkey/source/calendar/confvars.sh#53

Comment 33

[Benjamin Smedberg]

http://benjamin.smedbergs.us/blog/2005-07-29/the-testing-matrix/

I don't want to support (or pretend to support) arbitrary build flags that are only meant for small-device embedders. That calendar is disabling plugins (and Thunderbird is not packaging plugins.xpt) are bugs.

So if bug 391886 is FIXED, I think we should just patch configure and sunbird to disable the flag. Patch forthcoming.

Comment 34

[Benjamin Smedberg]

Attachment: Don't support that flag, rev. 1

Comment 35

[Robert Strong (they/them - no direct email)]

Comment on attachment 276470 [details] [diff] [review]
Don't support that flag, rev. 1

Would you file a bug to cleanup the remainder of MOZ_PLUGINS in the tree?

Comment 36

[Benjamin Smedberg]

To be clear, this does not remove the MOZ_PLUGINS setting: when building in --enable-embedding-profile=minimal plugins are still disabled. But since this mode also disables XUL and doesn't use the EM, we don't have to worry about it for this bug.

Comment 37

[Benjamin Smedberg]

I've landed the calendar/confvars.sh change. I didn't land the configure change because I've been rethinking it a little more and want to keep the flag and add an error message in some cases. But this bug as a calendar (and tbird) bug is FIXED.