Closed Bug 1081534 Opened 10 years ago Closed 10 years ago

icaljs is broken in Lightning nightly

Categories

(Calendar :: ICAL.js Integration, defect)

defect
Not set
critical

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: MakeMyDay, Assigned: MakeMyDay)

References

Details

(Keywords: regression)

Attachments

(1 file, 3 obsolete files)

Lightning Nightlies are broken, if icaljs is enabled. Error log: Timestamp: 11.10.2014 18:58:07 Error: NS_ERROR_XPC_CI_RETURNED_FAILURE: Component returned failure code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance] Source File: resource://calendar/modules/calUtils.jsm -> file:///F:/testprofiles/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calUtils.js Line: 17 Timestamp: 11.10.2014 18:58:07 Error: NS_ERROR_XPC_CI_RETURNED_FAILURE: Component returned failure code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance] Source File: resource://calendar/modules/calUtils.jsm -> file:///F:/testprofiles/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calUtils.js Line: 17 Timestamp: 11.10.2014 18:58:07 Error: NS_ERROR_XPC_CI_RETURNED_FAILURE: Component returned failure code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance] Source File: resource://calendar/modules/calUtils.jsm -> file:///F:/testprofiles/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calDateTimeFormatter.js Line: 26 Timestamp: 11.10.2014 18:58:07 Error: NS_ERROR_XPC_CI_RETURNED_FAILURE: Component returned failure code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance] Source File: resource://calendar/modules/calUtils.jsm -> file:///F:/testprofiles/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calDateTimeFormatter.js Line: 26 Timestamp: 11.10.2014 18:58:07 Error: NS_ERROR_XPC_CI_RETURNED_FAILURE: Component returned failure code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance] Source File: resource://calendar/modules/calUtils.jsm -> file:///F:/testprofiles/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calUtils.js Line: 17 Timestamp: 11.10.2014 18:58:07 Error: NS_ERROR_XPC_CI_RETURNED_FAILURE: Component returned failure code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance] Source File: resource://calendar/modules/calUtils.jsm -> file:///F:/testprofiles/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calUtils.js Line: 17 Timestamp: 11.10.2014 18:58:07 Error: NS_ERROR_XPC_CI_RETURNED_FAILURE: Component returned failure code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance] Source File: resource://calendar/modules/calUtils.jsm -> file:///F:/testprofiles/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calUtils.js Line: 17 Timestamp: 11.10.2014 18:58:08 Error: TypeError: listManager.setUpdateUrl is not a function Source File: resource://gre/components/nsPhishingProtectionApplication.js Line: 156 Timestamp: 11.10.2014 18:58:08 Error: NS_ERROR_XPC_CI_RETURNED_FAILURE: Component returned failure code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance] Source File: resource://calendar/modules/calUtils.jsm -> file:///F:/testprofiles/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calUtils.js Line: 17 Timestamp: 11.10.2014 18:58:08 Error: NS_ERROR_XPC_CI_RETURNED_FAILURE: Component returned failure code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance] Source File: resource://calendar/modules/calUtils.jsm -> file:///F:/testprofiles/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calUtils.js Line: 17 Timestamp: 11.10.2014 18:58:08 Error: NS_ERROR_XPC_CI_RETURNED_FAILURE: Component returned failure code: 0x80570015 (NS_ERROR_XPC_CI_RETURNED_FAILURE) [nsIJSCID.createInstance] Source File: resource://calendar/modules/calUtils.jsm -> file:///F:/testprofiles/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calDateTimeFormatter.js Line: 26 Timestamp: 11.10.2014 18:58:08 Error: NS_ERROR_XPC_GS_RETURNED_FAILURE: Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService] Source File: resource://calendar/modules/calUtils.jsm -> file:///F:/testprofiles/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calUtils.js Line: 92 Timestamp: 11.10.2014 18:58:09 Error: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [calIICSService.parseICS] Source File: resource://calendar/modules/calUtils.jsm -> file:///F:/testprofiles/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calIcsParser.js Line: 135 Timestamp: 11.10.2014 18:58:09 Error: NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [calIICSService.parseICS] Source File: resource://calendar/modules/calUtils.jsm -> file:///F:/testprofiles/commcentral/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calIcsParser.js Line: 135 Maybe this is related to the problem in bug 1074645?
Setting "dom.compartment_per_addon" back to false doesn't change the error, therefore probably not related to bug 1074645. Adding dump statements in calUtils.js it seems to fail when trying to load > _calIcalCreator called with cid=@mozilla.org/calendar/datetime;1 iid=calIDateTime Bug 1063085 changed several things related to calDateTime. Maybe this is regression from this bug?
The problem occures when calling cal.createDateTime() as you already mentioned above. So, it may be related to this, but I'm not sure as this came in early September. I had a try build on October, 5 for another icaljs issue which ran smoothly - so something afterwards must have caused this or at least unveiled a previously existing issue.
Keywords: regression
I tried the Thunderbird and nightly build from 01-Oct-2014 and they already show this error.
There's a massive gap in the TB nightlies on ftp.m.o, but I managed to work out that 2014-09-22 is good, and 2014-09-30 is bad. That really narrows it down. :-|
This is still hard to debug. It's obvious that this is a result of bug 1063085 (see also https://bugzilla.mozilla.org/show_bug.cgi?id=1082286#c3 ). To me it seems to be either a problem with the build changes or some race condition with the move of the jsdate replacement to calUtils.jsm (altough I'm not very familiar with the build stuff). Probably we should back the patch out, just reapply the calUtils.jsm stuff first and if everything is running come back to the build changes in a second step. Philipp, what do you think? And for the record: there are to additional occurrences of jsdate in the codebase which were not removed by the patch for bug 1063085 - even though this has currently no effect ;-) http://mxr.mozilla.org/comm-central/source/calendar/base/content/dialogs/calendar-event-dialog.js#2521 http://mxr.mozilla.org/comm-central/source/calendar/base/content/dialogs/calendar-event-dialog.js#3692
Flags: needinfo?(philipp)
Attached patch RevertBug1063085.diff (obsolete) (deleted) β€” β€” Splinter Review
Philipp, I've prepared a patch to revert the changes from bug 1063085, considering two changes in the C++ code. However, it doesn't build, there a five not linkable symbols when building for Windows (other platforms affected as well): calDateTime.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) class JSObject * __cdecl JS_NewDateObjectMsec(struct JSContext *,double)" (__imp_?JS_NewDateObjectMsec@@YAPAVJSObject@@PAUJSContext@@N@Z) referenced in function "public: virtual enum tag_nsresult __stdcall calDateTime::GetJsDate(struct JSContext *,class JS::MutableHandle<class JS::Value>)" (?GetJsDate@calDateTime@@UAG?AW4tag_nsresult@@PAUJSContext@@V?$MutableHandle@VValue@JS@@@JS@@@Z) calDateTime.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) class JSObject * __cdecl JS_NewDateObject(struct JSContext *,int,int,int,int,int,int)" (__imp_?JS_NewDateObject@@YAPAVJSObject@@PAUJSContext@@HHHHHH@Z) referenced in function "public: virtual enum tag_nsresult __stdcall calDateTime::GetJsDate(struct JSContext *,class JS::MutableHandle<class JS::Value>)" (?GetJsDate@calDateTime@@UAG?AW4tag_nsresult@@PAUJSContext@@V?$MutableHandle@VValue@JS@@@JS@@@Z) calDateTime.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall JSAutoCompartment::~JSAutoCompartment(void)" (__imp_??1JSAutoCompartment@@QAE@XZ) referenced in function "public: virtual enum tag_nsresult __stdcall calDateTime::SetJsDate(struct JSContext *,class JS::Handle<class JS::Value>)" (?SetJsDate@calDateTime@@UAG?AW4tag_nsresult@@PAUJSContext@@V?$Handle@VValue@JS@@@JS@@@Z) calDateTime.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) bool __cdecl JS_ObjectIsDate(struct JSContext *,class JS::Handle<class JSObject *>)" (__imp_?JS_ObjectIsDate@@YA_NPAUJSContext@@V?$Handle@PAVJSObject@@@JS@@@Z) referenced in function "public: virtual enum tag_nsresult __stdcall calDateTime::SetJsDate(struct JSContext *,class JS::Handle<class JS::Value>)" (?SetJsDate@calDateTime@@UAG?AW4tag_nsresult@@PAUJSContext@@V?$Handle@VValue@JS@@@JS@@@Z) calDateTime.obj : error LNK2019: unresolved external symbol "__declspec(dllimport) public: __thiscall JSAutoCompartment::JSAutoCompartment(struct JSContext *,class JSObject *)" (__imp_??0JSAutoCompartment@@QAE@PAUJSContext@@PAVJSObject@@@Z) referenced in function "public: virtual enum tag_nsresult __stdcall calDateTime::SetJsDate(struct JSContext *,class JS::Handle<class JS::Value>)" (?SetJsDate@calDateTime@@UAG?AW4tag_nsresult@@PAUJSContext@@V?$Handle@VValue@JS@@@JS@@@Z) calbasecomps.dll : fatal error LNK1120: 5 unresolved externals I'm not really familiar with the C++ code, so can you please take a look at this?
calIDateTime::jsDate was removed with Bug 1063085 because it had a dependency to the JS API methods mentioned above that are no longer available due to Bug 920731 and therefore caused build errors. You cannot undo the patch.
I think the only thing we can do to narrow this down is to bisect the m-c changes within the regression range we found.
Flags: needinfo?(philipp)
Attached patch RemoveNotxpcomFromIdl-V1.diff (obsolete) (deleted) β€” β€” Splinter Review
This is a regresssion of bug 1069518. Interfaces containing notxpcom definitions cannot be implemented in JS any more. The attached patch separates the interface definitions used by libical and icaljs and removes the not notxpcom attributes from the interfaces for the latter. Furthermore, the way to include the interfaces is handled again like before the patch for bug 1063085 landed. I have started a try build (1) and it builds on all platforms. The builds are available at (2) and the windows build works like expected again with icaljs enabled. Maybe somebody can check the Linux and Mac builds? (1) https://treeherder.mozilla.org/ui/#/jobs?repo=try-comm-central&revision=f0e7d27ec24b (2) http://ftp.mozilla.org/pub/mozilla.org/calendar/lightning/try-builds/makemyday@gmx-topmail.de-f0e7d27ec24b/
Assignee: nobody → makemyday
Attachment #8523551 - Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #8532551 - Flags: review?(philipp)
OS: Windows 7 → All
Hardware: x86_64 → All
Blocks: 1069518
Elevating this to critical given that it renders Lightning completely useless for current SeaMonkey releases (3.6b1 necessary for SM 2.31 is broken). If there is a workaround which we could add to the release notes, please post it.
Severity: normal → critical
Comment on attachment 8532551 [details] [diff] [review] RemoveNotxpcomFromIdl-V1.diff Review of attachment 8532551 [details] [diff] [review]: ----------------------------------------------------------------- Wow, kudos for regression hunting! You deserve something special for this :-) Sucks that we have to duplicate the idl files. Do you think we could instead make the base interface be the JS variant as you have them, then add something like calIDurationLibical that inherits from calIDuration and just contains the notxpcom stuff? r- to try that out, if it doesn't work please re-request.
Attachment #8532551 - Flags: review?(philipp) → review-
@Philipp: I'll give it a try. @rsx11m: to work around this, disable calendar.icaljs in the config editor. Once this is fixed, I will propose to backport this also to Aurora and Beta.
Thanks, I didn't try yet but posted the workaround in the release-note thread and MozillaZine.
Phillip, I have checked your proposal, but to me it looks like it needs more wide spreading changes also to libical and icaljs code to make this working due to the nested use of those four interfaces within themselves. So I suggest to live with duplicating the interfaces for now. If somebody else Once we have removed libical, we can move the idl's back to base/public. I will upload an updated version of the patch with new GUIDs and will request for review again. We should backport this also to Aurora and Beta then.
Attached patch RemoveNotxpcomFromIdl-V2.diff (obsolete) (deleted) β€” β€” Splinter Review
As mentioned before the same patch with updated GUIDs.
Attachment #8532551 - Attachment is obsolete: true
Attachment #8532961 - Flags: review?(philipp)
Attachment #8532961 - Flags: approval-calendar-beta?(philipp)
Attachment #8532961 - Flags: approval-calendar-aurora?(philipp)
Attached patch RemoveNotxpcomFromIdl-V3.diff (deleted) β€” β€” Splinter Review
Sorry, I forgot to include the removal of the two further occurences of jsDate mentioned in comment #5.
Attachment #8532961 - Attachment is obsolete: true
Attachment #8532961 - Flags: review?(philipp)
Attachment #8532961 - Flags: approval-calendar-beta?(philipp)
Attachment #8532961 - Flags: approval-calendar-aurora?(philipp)
Attachment #8532966 - Flags: review?(philipp)
Attachment #8532966 - Flags: approval-calendar-beta?(philipp)
Attachment #8532966 - Flags: approval-calendar-aurora?(philipp)
Comment on attachment 8532966 [details] [diff] [review] RemoveNotxpcomFromIdl-V3.diff Review of attachment 8532966 [details] [diff] [review]: ----------------------------------------------------------------- Ok, lets do it. r=philipp
Attachment #8532966 - Flags: review?(philipp)
Attachment #8532966 - Flags: review+
Attachment #8532966 - Flags: approval-calendar-beta?(philipp)
Attachment #8532966 - Flags: approval-calendar-beta+
Attachment #8532966 - Flags: approval-calendar-aurora?(philipp)
Attachment #8532966 - Flags: approval-calendar-aurora+
Keywords: checkin-needed
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 3.9
This got approval-calendar-aurora+ and approval-calendar-beta+ per comment #17, but this appears to have never landed on the branches, hence bug 1136890 against 3.8b1 is still unfixed? Querying comm-beta shows that this patch is present (but only due to the regular merges) whereas comm-release doesn't show any landing of this patch.
we don't merge to comm-release afaik. But you could check the THUNDERBIRD_36_0b1_RELEASE tag. Indeed it does look like it was only pushed to c-c. In 4.0 this has mostly been reverted anyway in bug 1142261.
Yes, this is not available in 3.8 and won't be. The workaround is to disable calendar.icaljs Bug 1136890 suffers from various overlapping problems, the icaljs was only one of it. See the recent comments on that bug.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: