Closed Bug 1125689 Opened 6 years ago Closed 6 years ago

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).

Categories

(SeaMonkey :: Build Config, defect)

defect
Not set
normal

Tracking

(seamonkey2.41 fixed)

RESOLVED FIXED
seamonkey2.41
Tracking Status
seamonkey2.41 --- fixed

People

(Reporter: ewong, Assigned: philip.chee)

Details

Attachments

(1 file, 1 obsolete file)

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..)
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.
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
Flags: needinfo?(iann_bugzilla)
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
Flags: needinfo?(iann_bugzilla)
Attached patch test for lightning (obsolete) — Splinter Review
You may know a better way of checking.
Attachment #8556837 - Flags: feedback?(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 on attachment 8556837 [details] [diff] [review]
test for lightning

f=WORKSFORME
Attachment #8556837 - Flags: feedback?(philip.chee) → feedback+
Attachment #8556837 - Flags: review?(neil)
(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 reply to neil@parkwaycc.co.uk 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
(In reply to neil@parkwaycc.co.uk 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)
(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 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.
Attachment #8556837 - Flags: review?(neil)
(In reply to neil@parkwaycc.co.uk 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.
> 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.
> 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
Assignee: nobody → philip.chee
Attachment #8556837 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8662964 - Flags: review?(iann_bugzilla)
Summary: Calendar not showing up in SeaMonkey due to __LOCATION__ missing. → Calendar not showing up in SeaMonkey due to __LOCATION__ missing (Error: ReferenceError: __LOCATION__ is not defined). Do not pack Lightning into a XPI.
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?)
Attachment #8662964 - Flags: review?(iann_bugzilla) → review+
Component: Lightning: SeaMonkey Integration → Build Config
OS: Windows 8.1 → All
Product: Calendar → SeaMonkey
Hardware: x86_64 → All
Target Milestone: --- → seamonkey2.41
Version: unspecified → Trunk
http://hg.mozilla.org/comm-central/rev/bda92538bc44
Status: ASSIGNED → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Summary: Calendar not showing up in SeaMonkey due to __LOCATION__ missing (Error: ReferenceError: __LOCATION__ is not defined). Do not pack Lightning into a XPI. → 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).
You need to log in before you can comment on or make changes to this bug.