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)

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

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

(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

> 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?

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

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

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

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

(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?

...or maybe a dupe of bug 667138?

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