1107865 - Lightning 3.6b1 does not work with SeaMonkey 2.31

Status: RESOLVED FIXED

(Calendar :: Lightning: SeaMonkey Integration, defect)

Description

[Peter Weilbacher]

I just installed SeaMonkey 2.31 and when restarting I got a non-compatibility note about the previously installed Lightning 3.5b1. So I updated to 3.6b1.

But when opening the Calendar or Tasks tabs in the SM mail window does not show any content. Instead, the window is resized to enormous horizontal dimension (far beyond the window), a toolbar appears but is greyed out and constantly flickers.

I also noticed that the timezone dropdown in Edit -> Preferences -> Calendar is not filled.

Comment 1

[Philip Chee]

Mc says: a workaround is to install the version from http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/candidates/3.6b1-candidates/build3/

Comment 2

[[:MakeMyDay]]

This is probably caused by the default setting for calendar.icaljs for builds up to Beta in combination with bug 1081534. Disabling that option in the config.editor and restarting SM should mitigate this issue.

Comment 3

[NoOp]

My comments from 11060334:
https://bugzilla.mozilla.org/show_bug.cgi?id=1106034#c9

<http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/candidates/3.6b1-candidates/build3/linux-x86_64/lightning-3.6b1.en-US.linux-x86_64.xpi>

per 1107865 and comments by Stephen Sitter on the dev list, and that works for me using:
User agent: Mozilla/5.0 (X11; Linux x86_64; rv:34.0) Gecko/20100101
Firefox/34.0 SeaMonkey/2.31
Build identifier: 20141202221415

I notice that when using that version, calendar.icaljs is set to false in 'about:config'. I'll do a ~/.mozilla backup & then try using the upgrade version w/calendar.icaljs set to false if it is set to true in that version.

https://bugzilla.mozilla.org/show_bug.cgi?id=1106034#c10

Loaded the addon update version & checked 'about:config' - calendar.icaljs is set to false. Changing to 'true' makes no difference. Reset to false & clicked the calendar icon, error console shows:

Timestamp: 12/05/2014 02:02:44 PM
Error: TypeError: Components.classes[cid] is undefined
Source File: resource://calendar/modules/calUtils.jsm -> file:///home/g/.mozilla/seamonkey/obfuscated.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calUtils.js
Line: 17

line 17 is:
let thing = Components.classes[cid].createInstance(iid);
in:
function _calIcalCreator(cid, iid) {
    return function(icalString) {
        let thing = Components.classes[cid].createInstance(iid);
        if (icalString) {
            thing.icalString = icalString;
        }
        return thing;

Comment 4

[Peter Weilbacher]

The "build3" mentioned in comment 1 works for me, too. Changing caljs in the other versions does not.

Switching caljs on with "build3" causes the calendar to work /very/ slowly, but it does still work.

Since I filed this bug, a Lightning 3.6b2 update became available and was offered to me via the Add-ons Manager. It does not fix this bug, though, independent of caljs setting.

Comment 6

[Jan Hoogenraad]

Before starting calendar or tasks, I noticed an error message that no plus sign (+) should be present in my gnome timezone setting (set to a string containing UTC+01).
Might this notice be somehow related ?

Comment 7

[Jan Hoogenraad]

Exact text:
Bad key or directory name: "/desktop/gnome/url-handlers/GMT+01/command": `+' is an invalid character in key/directory names
Bad key or directory name: "/desktop/gnome/url-handlers/GMT+01/command": `+' is an invalid character in key/directory names

Comment 8

[Peter Weilbacher]

Lightning 3.6b3 now does work with SM 2.31.

Was there a fix on purpose or did it just happen by chance? Will the problem come back with 3.6b4 or does someone test with SM before releasing Lightning?

Comment 9

[Attila K. MERGL]

What I saw (under Debian Wheezy) is the following.

Lightning 3.5b1 was working with SM 2.30 and the XPI file had the size of 4.5 MB.
Lightning 3.6b1 and 3.6b2 was NOT working any more with SM 2.31 and the XPI file got smaller (like the Windows version!) and had the size of 3.2 MB only.
Now 3.6b3 is larger again with 4.6 MB and it IS working.

So I compared the XPI flies (ZIP archives) and found the following difference:
3.6b2  /components  444.7 kB
                  /Linux_x86_64-gcc3  0 B
                  /Linux_x86-gcc3     0 B
3.6b3  /components    4.6 MB
                  /Linux_x86_64-gcc3  2.3 MB
                  /Linux_x86-gcc3     1.8 MB

So there was a packing problem while generating the XPI, wasn't it?
If you could avoid it in the future, the problem won't occur again.

Comment 10

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

The fix is to make sure my local merging script doesn't leave out the binary files. I try to do a quick test of the betas, but I don't always test all platforms.