669834 - Something happened in the main application code, which makes Lightning dysfunctional

Status: RESOLVED DUPLICATE of bug 667138

(Calendar :: Lightning Only, defect)

Description

[Tony Mechelynck [:tonymec]]

Good: Mozilla/5.0 (X11; Linux x86_64; rv:7.0a1) Gecko/20110705 Firefox/7.0a1 SeaMonkey/2.4a1 ID:20110705003257

Bad:  Mozilla/5.0 (X11; Linux x86_64; rv:8.0a1) Gecko/20110705 Firefox/8.0a1 SeaMonkey/2.4a1 ID:20110705091951

Same profile, same Lightning build (the last available linux64 comm-central nightly, from 20 June)

In "Good" SeaMonkey: Lightning works normally, except that bug 662718 (empty alarm at every startup) is present.

In "Bad" SeaMonkey:
- The symptoms of bug 662718 (which wasn't yet fixed in that Lightning build) are absent
- "Events and Tasks" menu is present in 3-pane MailNews window, but everything other than "Calendar" and "Tasks" is greyed out.
- After clicking "Events and Tasks → Calendar", the Calendar tab opens, but:
  - The Multiweek view (my usual) is displayed, but it is empty; above and right of it, "Day" (instead of "Multiweek" is selected
  - In the left pane, my calendars are listed, and above them the Mini-Month, but between them is an additional thing which I usually don't see: a list of radio buttons titled "Show", all greyed-out; the bottom one, which says "All", looks selected (dot in the middle of the circle)

Comment 1

[Tony Mechelynck [:tonymec]]

Oh, and one other thing: clicking "Month" "Week" or "Multiweek" above the main calendar grid elicits no reaction.

Comment 2

[Boris Zbarsky [:bzbarsky]]

What are the m-c changesets corresponding to those two builds?

Comment 3

[Tony Mechelynck [:tonymec]]

(In reply to comment #2)
> What are the m-c changesets corresponding to those two builds?

don't know, I would have to reinstall them and check about:buildconfig. I'll do that soon (and come back in maybe an hour or two) because my current installed build is "bad". In the meantime you could use the datestamps ("ID" in comment #0, which would be the same yyyyMMddhhmmss "build ID" as reported in a crash header).

In "Mozilla/5.0 (X11; Linux x86_64; rv:8.0a1) Gecko/20110707 Firefox/8.0a1 SeaMonkey/2.5a1" ID:20110707122803 (also bad, and built from http://hg.mozilla.org/mozilla-central/rev/763ff2d737e7) I see a lot of stuff in the Error Console. Don't know where to begin. Here are some examples, not in the order they appeared, and the first three are seen repeatedly:

Components.classes['@mozilla.org/calendar/datetime;1'] is undefined
(various locations)

Failed to check threadsafety!
resource://calendar/calendar-js/callcsParser-worker.js line 43

Error parsing ICS: Failed to check threadsafety!

Couldn't decrypt string = NS_ERROR_FAILURE
jar:file:///usr/local/seamonkey/omni.jar!/components/crypto-SDR.js line 205

and a long one:
Error: Message: Error selecting events with recurrence!
Connection Ready: true
Last DB Error Number: 100
Last DB Error Message: unknown error
Database File: /root/.mozilla/seamonkey/nexrdon9.default/calendar-data/cache.sqlite
Last DB Statement: [object StatementWrapper]
Last Statement param [cal_id]: 082cd0ff-9646-4350-afba-49ec90bbf06e
Exception: [Exception... "Component returned failure code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance]"  nsresult: "0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE)"  location: "JS frame :: resource://calendar/modules/calUtils.jsm -> file:///root/.mozilla/seamonkey/nexrdon9.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calUtils.js :: createEvent :: line 53"  data: no]
1: [file:///root/.mozilla/seamonkey/nexrdon9.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calStorageCalendar.js:2364] cSC_logError
2: [file:///root/.mozilla/seamonkey/nexrdon9.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calStorageCalendar.js:1326] cSC_assureRecurringItemCaches
3: [file:///root/.mozilla/seamonkey/nexrdon9.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calStorageCalendar.js:694] cSC_getItems_
4: [file:///root/.mozilla/seamonkey/nexrdon9.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/components/calStorageCalendar.js:647] null

Comment 4

[Boris Zbarsky [:bzbarsky]]

> In the meantime you could use the datestamps

I could, but since they're inaccurate by up to 6 hours, in my experience, it would noticeably increase the regression range size.

> Components.classes['@mozilla.org/calendar/datetime;1'] is undefined

Just to make sure... all the relevant bits got version-bumped, right?  If there's a binary component involved it was recompiled?

Comment 5

[Tony Mechelynck [:tonymec]]

First known "bad" build ("Firefox/8.0a1 SeaMonkey/2.4a1")
built from http://hg.mozilla.org/mozilla-central/rev/709b5696199b

Comment 6

[Tony Mechelynck [:tonymec]]

(In reply to comment #4)
[...]
> Just to make sure... all the relevant bits got version-bumped, right?  If
> there's a binary component involved it was recompiled?

about recompilation: the answer is no. No Linux64 comm-central lightning.xpi has been published since 20 June, because Philipp Kewisch "didn't want trouble during the Lightning 1.0b4 release" (which was from comm-miramar however). That 20 June Lightning build was the one I used, willy-nilly. But I didn't expect much change between SeaMonkey trunk builds only 9 hours apart.

About version-bump: I have the addon Compatibility Reporter extension enabled, and all possible relevant variants of extensions.checkCompatibility set to false.

Comment 7

[Tony Mechelynck [:tonymec]]

Last known good build ("Gecko/20110705 Firefox/7.0a1 SeaMonkey/2.4a1")
Built from http://hg.mozilla.org/mozilla-central/rev/26cce0d3e103

Comment 8

[Boris Zbarsky [:bzbarsky]]

> about recompilation: the answer is no.

Your regression range is http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=26cce0d3e103&tochange=709b5696199b

It includes http://hg.mozilla.org/mozilla-central/rev/d468f22484c9

Binary XPCOM components compiled against Gecko before that changeset will not be loaded when running against Gecko after that changeset.

That means that if Lightning relies on binary components it will be broken until it's recompiled against the new xpcom version.

Comment 9

[Tony Mechelynck [:tonymec]]

(In reply to comment #8)
> > about recompilation: the answer is no.
> 
> Your regression range is
> http://hg.mozilla.org/mozilla-central/
> pushloghtml?fromchange=26cce0d3e103&tochange=709b5696199b
> 
> It includes http://hg.mozilla.org/mozilla-central/rev/d468f22484c9
> 
> Binary XPCOM components compiled against Gecko before that changeset will
> not be loaded when running against Gecko after that changeset.
> 
> That means that if Lightning relies on binary components it will be broken
> until it's recompiled against the new xpcom version.

Aha! There is in Lightning something named (on Linux) components/libcalbasecomps.so and which has the executable bit set.

IOW, if I need the Mozilla Calendar, I will have to either take an old Sunbird out of mothballing, or remain with the above-mentioned "July 5 last good" SeaMonkey until Mr. Kewisch deigns to restart the comm-central Calendar builder for linux-x86_64.

I suppose this bug is either WONTFIX or INVALID then?

Comment 10

[Tony Mechelynck [:tonymec]]

...or maybe a dupe of bug 667138?

Comment 11

[Boris Zbarsky [:bzbarsky]]

As a core bug this is invalid.  No opinions on whether to dup it to something else or not as a Lightning bug.