518736 - Lightning options button in Add-on window error - looking for preferences.xul

Status: RESOLVED FIXED

(SeaMonkey :: Preferences, defect)

Description

[NoOp]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090923 Lightning/1.0pre SeaMonkey/2.0pre
Build Identifier: 

Clicking on the Lightning 'Preferences' button in the Add-on Manger (Tools|Add-on Manager) results in the following error:

The file jar:file:///home/<user>/SeaMonkey2/seamonkey/chrome/messenger.jar!/content/messenger/preferences/preferences.xul
cannot be found. Please check the location and try again.

And results in a 1x pixel blank SeaMonkey window.

Build identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090923 Lightning/1.0pre SeaMonkey/2.0pre

Lightning versions tested:
http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/nightly/linux-xpi/
lightning.xpi	24-Sep-2009
lightning.xpi	23-Sep-2009

The issue is that there is no /content/messenger/preferences/preferences.xul in SeaMonkey, unlike Thunderbird where I find that in 
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090915
Lightning/1.0pre Thunderbird/3.0b4
there is a messenger.jar, and it does have a content/messenger/preferencesfolder which includes preferences.xul.


Reproducible: Always

Comment 1

[Philip Chee]

To access the Lightning preferences in SeaMonkey: Edit->Preferences->Lightning.

Comment 2

[NoOp]

That of course works. The bug is filed as " Preferences button in Add-on window error - looking for preferences.xul"; not against 'Edit->Preferences->Lightning'.

Comment 3

[NoOp]

For Windows, option is: Tools|Add-on Manager|Extensions|Lightning|Options. The error shows:

The file jar:file:///C:/Program Files/SeaMonkey/chrome/messenger.jar!/content/messenger/preferences/preferences.xul cannot be found. Please check the location and try again.

Just tested with current nightlies for:
Build identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.4pre) Gecko/20090924 Lightning/1.0pre SeaMonkey/2.0pre

Comment 4

[Robert Kaiser]

Yes, that button is an issue, we are discussing variants of how to deal with it in the newsgroups, but it's not yet 100% clear how to fix that in an ideal case.

Comment 5

[NoOp]

Just remove it? As long as preferences can be configured via 'Edit->Preferences->Lightning' is the button really necessary in the Add-on Manager?

Comment 6

[Philip Chee]

There's *one* lightning.XPI for both Thunderbird and SeaMonkey. And Thunderbird is the reason for that Options button.

Comment 7

[NoOp]

Thunderbird also has 'Edit->Preferences->Lightning'.
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.4pre) Gecko/20090915 Lightning/1.0pre Thunderbird/3.0b4

Comment 8

[Philip Chee]

This menu item doesn't seem to exist on Windows (Shredder).

Comment 9

[NoOp]

Ok. How about: Tools|Options|Lightning

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9.1.4pre) Gecko/20090925 Lightning/1.0pre Shredder/3.0pre

Both from the current nightlies.

Comment 10

[Ian Neal]

Adding to suite/common/jar.mn:
%override chrome://messenger/content/preferences/preferences.xul chrome://communicator/content/pref/preferences.xul
gives a pref window but it is missing half the tree (only appearance, browser, privacy & security and advanced).
It also seg faults when you try to select a pref pane that would normally be overlayed.

Comment 11

[Ian Neal]

One option would be patch nsExtensionManager.js.in so that you can have <em:optionsURL> under each <em:targetApplication>

Comment 12

[Philip Chee]

> gives a pref window but it is missing half the tree (only appearance, browser,
> privacy & security and advanced).
> It also seg faults when you try to select a pref pane that would normally be
> overlayed.
I could have told you that!

> One option would be patch nsExtensionManager.js.in so that you can have
> <em:optionsURL> under each <em:targetApplication>

The chatzilla optionsURL does this:
<em:optionsURL>javascript:opener.openDialog('chrome://chatzilla/content/config.xul','','chrome,modal,resizable');window.close();</em:optionsURL>

So you might like to try something like:
javascript:url=Application.name=='Thunderbird'?foo:bar;opener.openDialog(url','','chrome,titlebar,toolbar,centerscreen,modal,resizable');window.close();

Comment 13

[Philip Chee]

Hacky, but this works for both Thunderbird and SeaMonkey:

javascript:var url=Application.name=='Thunderbird'?'chrome://messenger/content/preferences/preferences.xul':'chrome://communicator/content/pref/preferences.xul';opener.openDialog(url,'','chrome,titlebar,toolbar,centerscreen,modal,resizable');window.close();

Hmm. Or would it be better to test for Application.name=='SeaMonkey'?

Comment 14

[Karsten Düsterloh]

How about Application.id?
"{3550f703-e582-4d05-9a08-453d09bdfdc6}" => Thunderbird
"{92650c4d-4b8e-4d2a-b7eb-24ecf4f6b63a}" => SeaMonkey

Comment 15

[Philip Chee]

Far less readable, unless your native language is UUID.

Comment 16

[Ian Neal]

Whilst you are touching that file you could change the description so it says something more than "An integrated calendar for Thunderbird"

Comment 17

[Philip Chee]

> Whilst you are touching that file you could change the description so it says
> something more than "An integrated calendar for Thunderbird"
Who's touching what file? We don't have a consensus as to the correct approach yet, have we?

Comment 18

[Karsten Düsterloh]

(In reply to comment #15)
> Far less readable, unless your native language is UUID.

Well, but it's "more" correct. Names may change or reflect a different context, UUIDs shouldn't. And comments exist! ;-)

Comment 19

[Philip Chee]

Attachment: Patch Pv1.0 An independent prefwindow.

The Firefox/toolkit devs have consistently discouraged extension authors from overlaying their preferences UI on to the application prefwindow because well this approach will fail the UI if more than a handful of extensions add their own prefpanes.

The approach of this patch is to create a standalone prefwindow accessible via the addons manager.

Comment 20

[Philip Chee]

Attachment: Patch Ov1.0 Javascript <optionsURL>

As discussed in Comment 13 and Comment 14, this approach uses a javascript hack in the <optionsURL> to select which prefwindow (Thunderbird/SeaMonkey) to use. Also uses an optional parameter to switch to the Lightning prefpane in Thunderbird.

Comment 21

[[e-mail]]

Comment on attachment 404243 [details] [diff] [review]
Patch Ov1.0 Javascript <optionsURL>

Eww, how cheesy :-(

Comment 22

[[e-mail]]

Comment on attachment 404239 [details] [diff] [review]
Patch Pv1.0 An independent prefwindow.

>diff --git a/calendar/lightning/content/preferences.xul b/calendar/lightning/content/preferences.xul
>new file mode 100644
What's the difference between this file and calendar/base/content/preferences/preferences.xul?
I don't understand your other changes either.

Comment 23

[Philip Chee]

(In reply to Comment #21)
> (From update of attachment 404243 [details] [diff] [review])
> Eww, how cheesy :-(
Do you have a better idea then?

Comment 24

[Ian Neal]

(In reply to comment #19)
> Created an attachment (id=404239) [details]
> Patch Pv1.0 An independent prefwindow.
> 
This seems to be missing a few changes, you've removed some files in the jar.mn but not the actual files. Are you still overlaying SM prefs?

Comment 25

[Philip Chee]

>> Patch Pv1.0 An independent prefwindow.
> This seems to be missing a few changes, you've removed some files in the jar.mn
> but not the actual files.
Yeah, I forgot.

> Are you still overlaying SM prefs?
Yes I am. The two files in jar.mn are solely for overlaying the TB preference window and don't affect the SM overlay.

Comment 26

[Ian Neal]

(In reply to comment #25)
> >> Patch Pv1.0 An independent prefwindow.
> > Are you still overlaying SM prefs?
> Yes I am. The two files in jar.mn are solely for overlaying the TB preference
> window and don't affect the SM overlay.
So for SM there would be two separate pref windows, one for everything including lightning and accessed via the Edit menu, and one accessed from the Add-on Manager?
For TB you could only access the pref window from the Add-on Manager?

Comment 27

[Philip Chee]

> So for SM there would be two separate pref windows, one for everything
> including lightning and accessed via the Edit menu, and one accessed from the
> Add-on Manager?
Yes.

> For TB you could only access the pref window from the Add-on Manager?
I guess I should leave those overlay files untouched then.

Comment 28

[Philip Chee]

Attachment: Patch Pv1.1 Prefwindow without touching existing Thunderbird overlays.

Standalone prefwindow for Lightning without removing any of the Thunderbird overlays. Basically this is just the Sunbird preference window without the Advanced prefpane which contains the application preferences not applicable to an extension.

Comment 29

[Martin Schröder [:mschroeder]]

Comment on attachment 405261 [details] [diff] [review]
Patch Pv1.1 Prefwindow without touching existing Thunderbird overlays.

This needs additional Calendar review, or better a decision from the Calendar project lead first!

Comment 30

[Simon Paquet [:sipaq]]

Martin is right, please always get a review from a Calendar peer when touching our code.

On a different matter: 
I'm really not happy with all these added files for SeaMonkey support, which just bloats up our XPI for the large majority of our users. I think it would be more appropriate if those files would be packaged directly with SeaMonkey and not with our package.

Comment 31

[Ian Neal]

(In reply to comment #30)
> Martin is right, please always get a review from a Calendar peer when touching
> our code.
> 
I think Philip was always going to ask for a Calendar peer review, he was just waiting for a review from Neil first.

> On a different matter: 
> I'm really not happy with all these added files for SeaMonkey support, which
> just bloats up our XPI for the large majority of our users. I think it would be
> more appropriate if those files would be packaged directly with SeaMonkey and
> not with our package.
I think the best route is try and get the coding so that common overlays can be used for both TB and SM, and that might mean changes to:
Toolkit - to make it more flexible
SM - to match ids / APIs
Lightning - to make it more agnostic to the application it is extending (without causing bloat)

Comment 32

[Wyatt Childers]

(In reply to comment #31)
> (In reply to comment #30)
> > Martin is right, please always get a review from a Calendar peer when touching
> > our code.
> > 
> I think Philip was always going to ask for a Calendar peer review, he was just
> waiting for a review from Neil first.
> 
> > On a different matter: 
> > I'm really not happy with all these added files for SeaMonkey support, which
> > just bloats up our XPI for the large majority of our users. I think it would be
> > more appropriate if those files would be packaged directly with SeaMonkey and
> > not with our package.
> I think the best route is try and get the coding so that common overlays can be
> used for both TB and SM, and that might mean changes to:
> Toolkit - to make it more flexible
> SM - to match ids / APIs
> Lightning - to make it more agnostic to the application it is extending
> (without causing bloat)

I like the idea of adding Sunbird or Lightning. I think if SeaMonkey is the Mozilla application suite then it should have the Mozilla Calender am i not right? Why not bundle it in 2.1 when they are probably going to update the Composer. Who knows maybe SeaMonkey 2.1 will do the same as Firefox 3.1.

Comment 33

[[e-mail]]

Comment on attachment 404243 [details] [diff] [review]
Patch Ov1.0 Javascript <optionsURL>

Would it be possible for SeaMonkey to package a messenger/preferences.xul which only exists for that Options button, and just displays Lightning options?

Comment 34

[Philip Chee]

> Would it be possible for SeaMonkey to package a messenger/preferences.xul which
> only exists for that Options button, and just displays Lightning options?

I don't see how. And it would be fragile every time Mossop changes the Addons Manager UI or API.

I could package a dummy chrome://messenger/content/preferences/preferences.xul but that would be visible to all extensions.

Comment 35

[Robert Kaiser]

Attachment: override trick, v1

The override trick in this patch works at least partially. Unfortunately, the pref window this calls up is not complete, probably because it still thinks it is living at the original Thunderbird window address...

Comment 36

[Philip Chee]

> I could package a dummy chrome://messenger/content/preferences/preferences.xul

That opens the seamonkey preference window and then closes itself.

> but that would be visible to all extensions.

Comment 37

[Philip Chee]

Moving over to SeaMonkey product. Sorry for the bugspam.

Comment 38

[Philip Chee]

Attachment: 191Branch Patch Ev1.0 Overlay extensions.xul

Overlay the Add-on Manager. Extremely Hacky but fits Neils specification that only Lightning will be redirected to the Suite Preferences window. This patch is against the 1.9.1 branch as the EM API there is stable and effectively frozen.

> +  var commands = gExtensionsViewController.commands;
> +  commands._sm_cmdOptions = commands.cmd_options;
> +
> +  commands.cmd_options = function cmd_options(aSelectedItem) {

Override the EM method that opens the extension options dialog/window.

Comment 39

[Robert Kaiser]

(In reply to comment #37)
> Moving over to SeaMonkey product. Sorry for the bugspam.

Not sure why this would be the right thing to do, but as long as it gets solved without putting more unneeded stuff like an actual "messenger" prefwindow into SeaMonkey code, I'm happy.

Comment 40

[Robert Kaiser]

Comment on attachment 451085 [details] [diff] [review]
191Branch Patch Ev1.0 Overlay extensions.xul

IMHO, putting Lightning code into SeaMonkey proper is wrong unless we're shipping Lightning as a non-add-on built-in suite component.

Comment 41

[Wyatt Childers]

(In reply to comment #40)
> (From update of attachment 451085 [details] [diff] [review])
> IMHO, putting Lightning code into SeaMonkey proper is wrong unless we're
> shipping Lightning as a non-add-on built-in suite component.

Perhaps this is what should be done. As I understand SeaMonkey is ment to be a "group" of Mozilla's software or originally it was. Thus the calendar should be included. The way I see it there is nothing this could hurt. In other words I'm in favor of adding it to the suite.

Comment 42

[Robert Kaiser]

Wyatt, are you volunteering to watch over and maintain all code of this module inside SeaMonkey? If so, please contact us, as such a maintainer/owner would be a requirement for doing what you propose. In any case, this bug is not the forum to discuss doing that eventually.

Comment 43

[Wyatt Childers]

(In reply to comment #42)
> Wyatt, are you volunteering to watch over and maintain all code of this module
> inside SeaMonkey? If so, please contact us, as such a maintainer/owner would be
> a requirement for doing what you propose. In any case, this bug is not the
> forum to discuss doing that eventually.

I would but I'm still learning Mozilla code and how it works at the moment all I can do is test and report bugs.

Comment 44

[Philip Chee]

Lightning 1.0b1 is the version that is aimed at SeaMonkey 2.0. Unfortunately it has already shipped. There are no more nightlies on 1.9.1 and there it is very unlikely that any more updates will be released on 1.9.1. So this branch patch has to be in SeaMonkey.

Comment 45

[Robert Kaiser]

Well, I for myself care more about trunk/2.1 than branch/2.0 as long as this is not yet fixed on trunk.

Comment 46

[Ian Neal]

(In reply to comment #45)
> Well, I for myself care more about trunk/2.1 than branch/2.0 as long as this is
> not yet fixed on trunk.

Is it me or does the new add-on manager not have an options button anymore for extensions?

Comment 47

[Robert Kaiser]

(In reply to comment #46)
> Is it me or does the new add-on manager not have an options button anymore for
> extensions?

It's not a button right now, but the item in the context menu is there. I agree though that a button would be nice.

Comment 48

[Philip Chee]

> It's not a button right now, but the item in the context menu is there. I agree
> though that a button would be nice.

Exactly!

I can make a trunk patch to do this (I have the code running locally) but I'm holding back until the UI (and API) stabilizes since I don't want to do useless work.

Comment 49

[[e-mail]]

(In reply to comment #34)
>> Would it be possible for SeaMonkey to package a messenger/preferences.xul which
>> only exists for that Options button, and just displays Lightning options?
> I don't see how. And it would be fragile every time Mossop changes the Addons
> Manager UI or API.
I think you misunderstood. I mean that when someone (presumably the addons manager) opens messenger/preferences.xul it will display Lightning's options.

> I could package a dummy chrome://messenger/content/preferences/preferences.xul
> but that would be visible to all extensions.
What's wrong with that?

Comment 50

[Philip Chee]

>>> Would it be possible for SeaMonkey to package a messenger/preferences.xul which
>>> only exists for that Options button, and just displays Lightning options?
>> I don't see how. And it would be fragile every time Mossop changes the Addons
>> Manager UI or API.
> I think you misunderstood. I mean that when someone (presumably the addons
> manager) opens messenger/preferences.xul it will display Lightning's options.

Isn't that what my latest patch does (on SeaMonkey)?

>> I could package a dummy chrome://messenger/content/preferences/preferences.xul
>> but that would be visible to all extensions.
> What's wrong with that?

Err, I thought that you wanted it visible only to Lightning? Or was that someone else? No I'm not going to read all the comments from the beginning again.

Comment 51

[Sven Grull]

(In reply to comment #46)

> Is it me or does the new add-on manager not have an options button anymore for
> extensions?

In the overview there is no preference button, you have to switch (double click) to detailed view to see this button.

Comment 52

[[e-mail]]

(In reply to comment #50)
> > I mean that when someone (presumably the addons manager) opens
> > messenger/preferences.xul it will display Lightning's options.
> Isn't that what my latest patch does (on SeaMonkey)?
The one I see hacks the addons manager to rewrite the effect of the button.

> Err, I thought that you wanted it visible only to Lightning?
No, you misunderstood me; my guess is when I said "only exists for that Options button maybe I should have said "only exists because of that Options button."

Comment 53

[Philip Chee]

Attachment: Patch Mv1.0 Stub messenger preferences.xul [SM2.0]

This adds a stub chrome://messenger/content/preferences/preferences.xul for Lightning to overlay and call.

Comment 54

[[e-mail]]

Comment on attachment 456447 [details] [diff] [review]
Patch Mv1.0 Stub messenger preferences.xul [SM2.0]

>+<?xml-stylesheet type="text/css" href="chrome://communicator/skin/"?>
[You may only need chrome://global/skin/ which would avoid xpfe="false"]

>+<?xml-stylesheet type="text/css" href="chrome://communicator/skin/preferences.css"?>
I don't think you should import this, this is a binding stylesheet.

>+<?xml-stylesheet href="chrome://messenger/content/messenger.css"?>
I don't think we need this either.

Comment 55

[Ian Neal]

(In reply to comment #53)
> Created attachment 456447 [details] [diff] [review]
> Patch Mv1.0 Stub messenger preferences.xul [SM2.0]
> 
> This adds a stub chrome://messenger/content/preferences/preferences.xul for
> Lightning to overlay and call.

Unfortunately, until lightning works on trunk, I cannot really test this.

Comment 56

[Philip Chee]

> Unfortunately, until lightning works on trunk, I cannot really test this.

> Created attachment 456447 [details] [diff] [review]
> Patch Mv1.0 Stub messenger preferences.xul [SM2.0]
Arrr? IanN this is a branch patch [SM2.0]

Comment 57

[Ian Neal]

(In reply to comment #56)
> > Unfortunately, until lightning works on trunk, I cannot really test this.
> 
> > Created attachment 456447 [details] [diff] [review]
> > Patch Mv1.0 Stub messenger preferences.xul [SM2.0]
> Arrr? IanN this is a branch patch [SM2.0]

Looks like i'll have to dig out my SM2.0 tree then

Comment 58

[Philip Chee]

Attachment: [Checked-in] Patch Mv1.1 Stub messenger preferences.xul [SM2.0] r=IanN sr=Neil a2.0.7=KaiRo

Patch for checkin. Carrying forward r=IanN sr=Neil

Requesting a=2.0.7. Low risk. Allows the options button in the Lightning entry in the Addons Manager to call something that doesn't error out.

Comment 59

[Robert Kaiser]

Comment on attachment 460874 [details] [diff] [review]
[Checked-in] Patch Mv1.1 Stub messenger preferences.xul [SM2.0] r=IanN sr=Neil a2.0.7=KaiRo

You didn't want to request approval for Gecko 2.0 but SeaMonkey 2.0.7, right? :P

Comment 60

[Philip Chee]

Pushed to comm-1.9.1
http://hg.mozilla.org/releases/comm-1.9.1/rev/9a18f52bec74

Closing bug finally. Phew!

Comment 61

[Stefan Sitter [:ssitter]]

Based on user report it still seems to fail in SeaMonkey 2.1b2pre. Did this land on comm-central at all? Was it forgotten or not checked in on purpose?

Comment 62

[Jens Hatlak (:InvisibleSmiley)]

(In reply to comment #61)
> Based on user report it still seems to fail in SeaMonkey 2.1b2pre. Did this
> land on comm-central at all?

No.

> Was it forgotten or not checked in on purpose?

See comment 48. I think that's the last update on that.