1125689 - Lightning isn't working in SeaMonkey due to __LOCATION__ missing (Error: ReferenceError: __LOCATION__ is not defined). Do not pack Lightning into a XPI. Also leaves the default theme unpacked (needed for Bug 1189918).

Status: RESOLVED FIXED

(SeaMonkey :: Build Config, defect)

Description

[Edmund Wong (:ewong)]

Building trunk SeaMonkey with --enable-calendar in the .mozconfig results
in the right menu items but no Calendar view.

Looking at the Error Console, I see the following when I open the
Mail & Newsgroup window:

Timestamp: 1/26/2015 9:15:40 AM
Error: ReferenceError: __LOCATION__ is not defined
Source File: resource://calendar/modules/calUtils.jsm
Line: 36
( repeated 25 times ) then I get:

Timestamp: 1/26/2015 9:23:51 AM
Error: NS_ERROR_XPC_CI_RETURNED_FAILURE: Component returned failure code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance]
Source File: chrome://calendar/content/calUtils.js
Line: 1846

then 

Timestamp: 1/26/2015 9:23:51 AM
Error: ReferenceError: __LOCATION__ is not defined
Source File: resource://calendar/modules/calUtils.jsm
Line: 36

( x 2)

then:

Timestamp: 1/26/2015 9:23:51 AM
Error: NS_ERROR_XPC_CI_RETURNED_FAILURE: Component returned failure code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance]
Source File: chrome://calendar/content/calUtils.js
Line: 1846

then:

Timestamp: 1/26/2015 9:23:51 AM
Error: ReferenceError: __LOCATION__ is not defined
Source File: resource://calendar/modules/calUtils.jsm
Line: 36

then 

Timestamp: 1/26/2015 9:23:51 AM
Error: NS_ERROR_XPC_GS_RETURNED_FAILURE: Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]
Source File: chrome://calendar/content/calUtils.js
Line: 68

(etc..)

Comment 1

[Edmund Wong (:ewong)]

There is an issue with the current SeaMonkey 'integration' via the
'add_ac_options --enable-calendar' in .mozconfig build.

I get this bug if I do the following:

1) Add 'add_ac_options --enable-calendar' to .mozconfig
2) do the regular SeaMonkey build.
3) Run the build.
4) It will tell you that Lightning is disabled.  Enable it. Restart SeaMonkey
5) You will get this bug when you run SeaMonkey again with Calendar enabled.

Disable Lightning in Add-ons and restart.

Here's a way to work around this bug.

a) like #1-#3.
b) In Add-on manager, click on the gear icon and click on "Install Add-on
from file"
c) Go into the objdir/dist/xpi-stage folder and select the Lightning???.xpi file.
d) Allow it to install and restart SeaMonkey.
e) In Mail & Newsgroups, you can now see the calendar portion.

Something is missing with the initial Lightning install.

Comment 2

[Philip Chee]

The Lightning in dist/bin/extensions/ is packed. Since it has a binary component it should be unpacked. IanN made our builds generate packed extensions. -> IanN

Comment 3

[Ian Neal]

I guess the easiest way of fixing this is to check if dir is the lightning one and in that case not pack.
http://hg.mozilla.org/comm-central/annotate/9c7f3c9bc127/suite/app/Makefile.in#l94

Comment 4

[Ian Neal]

Attachment: test for lightning

You may know a better way of checking.

Comment 5

[Philip Chee]

> You may know a better way of checking.
I have no clue how this works. But I can test this patch no problem.

Comment 6

[Philip Chee]

Comment on attachment 8556837 [details] [diff] [review]
test for lightning

f=WORKSFORME

Comment 7

[[e-mail]]

(In reply to Philip Chee from comment #2)
> The Lightning in dist/bin/extensions/ is packed. Since it has a binary
> component it should be unpacked. IanN made our builds generate packed
> extensions. -> IanN

IanN also made our builds generate extensions in dist/bin/distribution/extensions rather than dist/bin/extensions. Should we be trying to pack extensions in dist/bin/extensions?

Comment 8

[Philipp Kewisch [:Fallen][📱📆]]

(In reply to [e-mail] from comment #7)
> (In reply to Philip Chee from comment #2)
> > The Lightning in dist/bin/extensions/ is packed. Since it has a binary
> > component it should be unpacked. IanN made our builds generate packed
> > extensions. -> IanN
> 
> IanN also made our builds generate extensions in
> dist/bin/distribution/extensions rather than dist/bin/extensions. Should we
> be trying to pack extensions in dist/bin/extensions?

As I've understood dist/bin/distrubution/extensions, it would be okay to have them packed there? What should happen is that they are taken from dist/bin/distribution/extensions and installed into the profile. The installing into the profile should be doing the unpacking.

If the distribution folder is working for you I'd keep it this way, installing into dist/bin/extensions ins being deprecated eventually, especially since on mac it would disrupt signed builds since a new binary component is dropped into SeaMonkey.app/Contents/Resources/extensions

Comment 9

[Philip Chee]

(In reply to [e-mail] from comment #7)
> (In reply to Philip Chee from comment #2)
>> The Lightning in dist/bin/extensions/ is packed. Since it has a binary
>> component it should be unpacked. IanN made our builds generate packed
>> extensions. -> IanN
> 
> IanN also made our builds generate extensions in
> dist/bin/distribution/extensions rather than dist/bin/extensions. Should we
> be trying to pack extensions in dist/bin/extensions?

In general extensions should be packed unless they contain a binary component.

Current situation:
In dist/bin/distribution/extensions:
debugQA
Inspector
Chatzilla

In dist/bin/extensions:
Lightning (Packed)
Modern
Classic (stub)
Provider for Google Calendar

After make package in the ZIP file:
In seamonkey/distribution/extensions:
debugQA (not in release builds)
Inspector
Chatzilla

In seamonkey/extensions:
Modern
Classic (stub)

Comment 10

[[e-mail]]

(In reply to Philipp Kewisch from comment #8)
> As I've understood dist/bin/distrubution/extensions, it would be okay to
> have them packed there? What should happen is that they are taken from
> dist/bin/distribution/extensions and installed into the profile. The
> installing into the profile should be doing the unpacking.

Actually that's not true, they just get copied (so we're shipping neither DOM Inspector nor ChatZilla correctly, as they both specify em:unpack in their install.rdf).

We can't actually package them unpacked because the build system tries to omnijar all the interfaces and manifests, which fails quite spectacularly.

> If the distribution folder is working for you I'd keep it this way,
> installing into dist/bin/extensions ins being deprecated eventually,
> especially since on mac it would disrupt signed builds since a new binary
> component is dropped into SeaMonkey.app/Contents/Resources/extensions

As I understand it Lightning isn't being built in distribution.

(In reply to Philip Chee from comment #9)
> In dist/bin/extensions:
> Modern

Well there goes my idea.

Comment 11

[[e-mail]]

Comment on attachment 8556837 [details] [diff] [review]
test for lightning

Since we can't currently legitimately build a complete SeaMonkey+Lightning package, developers who want to build Lightning should use --enable-chrome-format=flat to disable extension packing.

Comment 12

[Philipp Kewisch [:Fallen][📱📆]]

(In reply to [e-mail] from comment #10)
> We can't actually package them unpacked because the build system tries to
> omnijar all the interfaces and manifests, which fails quite spectacularly.
This is bug 910660 by the way, which I would like to fix soon because it also blocks me from including Lightning in Thunderbird's nightly builds.


> 
> > If the distribution folder is working for you I'd keep it this way,
> > installing into dist/bin/extensions ins being deprecated eventually,
> > especially since on mac it would disrupt signed builds since a new binary
> > component is dropped into SeaMonkey.app/Contents/Resources/extensions
> 
> As I understand it Lightning isn't being built in distribution.
Right, we copy to Contents/Resources because this works better for developers. If you want it in the distribution folder for packaging, I'm sure we can carve out some sort of flag for it.

Comment 13

[Philip Chee]

> Since we can't currently legitimately build a complete SeaMonkey+Lightning
> package, developers who want to build Lightning should use
> --enable-chrome-format=flat to disable extension packing.

I prefer IanN's fix since only Lightning is unpacked.
BTW if Lighting is meant to be installed unpacked, I would like the chrome/calendar/, chrome/lightning/, and chrome/skin/ directories to be packed into a jar file but that's for another bug.

Comment 14

[Philip Chee]

Attachment: Patch v1.0 Do not pack Lightning and the Default Theme.

> You may know a better way of checking.
I read the Make manuals. And found a better way.
Also leave the Default Theme unpacked - needed for Bug 1189918

Comment 15

[Ian Neal]

Comment on attachment 8662964 [details] [diff] [review]
Patch v1.0 Do not pack Lightning and the Default Theme.

r=me a=me for CLOSED TREE (does bug more belong under SM Build Config now?)

Comment 16

[Philip Chee]

http://hg.mozilla.org/comm-central/rev/bda92538bc44