Closed Bug 919018 Opened 11 years ago Closed 11 years ago

CalDAV provider not working in SeaMonkey because it references Http.jsm that is not available

Categories

(SeaMonkey :: General, defect)

SeaMonkey 2.21 Branch
defect
Not set
critical

Tracking

(seamonkey2.21 affected, seamonkey2.22 unaffected)

RESOLVED WONTFIX
Tracking Status
seamonkey2.21 --- affected
seamonkey2.22 --- unaffected

People

(Reporter: ssitter, Unassigned)

References

Details

Since the release of Lightning 2.6 I have seen some reports that CalDAV is not working. One of them showed the following error:

> Error: NS_ERROR_FILE_NOT_FOUND: Component returned failure code:
> 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIXPCComponents_Utils.import]
> File: resource://calendar/modules/OAuth2.jsm
> Line: 12

> Error: [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 ::
> [...]calendar-js/calCalendarManager.js :: cmgr_createCalendar ::
> line 474" data: no]

Based on the error message the problem is clear. CalDAV provider includes OAuth2.jsm that tries to load Http.jsm. Unfortunately Http.jsm is only available in Thunderbird on the mozilla24 branch. Bug 884319 moved Http.jsm to Toolkit but is fixed only on the mozilla25 branch.

Because Http.jsm doesn't exist in SeaMonkey the CalDAV provider fails to initialize.
Is there any way to fix this Lightning wise for version 2.6 and SeaMonkey 2.12? Is it possible to just manually add Http.jsm somewhere in SeaMonkey as a workaround?
Http.jsm isn't in Thunderbird 24 either. It's called http.jsm with a lower-case h.
A workaround is to add http.jsm to omni.ja in SeaMonkey, this way calendars work. But we should really think about fixing this in the next six weeks. Should I open a bug in the SeaMonkey component to add http.jsm in omni.ja on their side?
See also bug 884319. Adding it to SM is only required for releases that don't contain the patches there. I think its fine to move this bug to Seamonkey because there is nothing ad-hoc we can do about this.
Component: Provider: CalDAV → General
Product: Calendar → SeaMonkey
Version: Lightning 2.6 → unspecified
(In reply to Iacopo Benesperi [:iacchi] from comment #3)
> A workaround is to add http.jsm to omni.ja in SeaMonkey, this way calendars
> work. But we should really think about fixing this in the next six weeks.
> Should I open a bug in the SeaMonkey component to add http.jsm in omni.ja on
> their side?
Once you're on Mozilla 25 there's nothing to do as Http.jsm is provided by toolkit. It was noted somewhere in bug 884319 that depending on http.jsm for Lightning was a bad idea as it's a file provided only to Thunderbird. SeaMonkey could potentially package this file for the moz24 branch, I suppose. The correct file to use is [1] (there's a second copy under chat/, don't use that one).

[1] http://mxr.mozilla.org/comm-release/source/mail/base/modules/http.jsm
Ah ok, so this is only for Mozilla 24 on Seamonkey. I guess its up to Seamonkey then if they want to package this, their next release will be in less than 6 weeks anwyay.
Depends on: 884319
So with the next SeaMonkey release this will be fixed? I guess this bug here is probably a WONTFIX then.
Version: unspecified → SeaMonkey 2.21 Branch
Jens: Can you add a note to the SeaMonkey 2.21 release notes under "Known Issues" that the CalDAV protocol does not work in Lightning? This issue should be SeaMonkey 2.21 only and will be fixed in SeaMonkey 2.22. Thanks!
(In reply to Frank Wein [:mcsmurf] from comment #9)
> Jens: Can you add a note to the SeaMonkey 2.21 release notes under "Known
> Issues" that the CalDAV protocol does not work in Lightning? This issue
> should be SeaMonkey 2.21 only and will be fixed in SeaMonkey 2.22. Thanks!

Done (see bug 906974 comment 3).
Hi,
SeaMonkey 2.22 has been released as well as Lightning 2.7b1, but the problem is still there. The OAuth window doesn't appear and it's not possible to connect to the calendar (at least for writing on it).
There is still Bug 901332 open.
In SeaMonkey 2.21 all CalDAV calendars were broken. Can you verify that CalDAV works again in SeaMonkey 2.22 when using a CalDAV server different to Google?
Yes, I can confirm that. The old CalDAV url that doesn't require OAuth for GCalendar still works and the calendar works with that url.
I am STILL getting this error

[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:///[...]/SeamonkeyProfile/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js :: cmgr_createCalendar :: line 474"  data: no]

Seamonkey 2.22 Build identifier: 20131028182244
Lightning 2.6.2
CalDav calendar sits on an owncloud server

What's wrong with this? Is the same as Bug 901332?
I now have to back to build 2.20 again!?
Lightning 2.6 is for SeaMonkey 2.21. Use Lightning 2.7 Beta for SeaMonkey 2.22: https://addons.mozilla.org/thunderbird/addon/lightning/versions/2.7b1
Resolving as wontfix according to the comments above. The issue described here was mentioned in the SeaMonkey 2.21 release notes and SeaMonkey 2.22 was released.
Status: NEW → RESOLVED
Closed: 11 years ago
Resolution: --- → WONTFIX
Stefan, sorry but I think you're wrong here. CalDAV is still not working if http.jsm is needed for OAuth authentication in SeaMonkey. I know that this is more related to bug 901332 but can we leave this open, too, until everything starts to work again?
The only reason I can think of to reopen this bug is that the SeaMonkey developers decide to do a bugfix release of SeaMonkey 2.21 that includes http.jsm. SeaMonkey 2.22 and newer already include the file and are not affected by this bug.

The problem with SeaMonkey and Google CalDAV OAuth2 authentication is already tracked with Bug 901332 therefore I don't see any reason to convert this bug into a duplicate of Bug 901332.
You're right here but bug 901332 is Lightning-related and I was wondering if this problem is caused by Lightning or SeaMonkey (but maybe in this case we should open a new bug or change the product of 901332 rather than keeping this opened, I don't know).
Also, in comment #2 Geoff states that the file is called http.jsm (lowercase) while in SeaMonkey 2.22 there's Http.jsm (uppercase) so that may be a problem?
(In reply to Iacopo Benesperi [:iacchi] from comment #20)
> You're right here but bug 901332 is Lightning-related and I was wondering if
> this problem is caused by Lightning or SeaMonkey (but maybe in this case we
> should open a new bug or change the product of 901332 rather than keeping
> this opened, I don't know).
It does not seem like anyone knows the cause of bug 901332 yet, so it would probably be premature to change the component.

> Also, in comment #2 Geoff states that the file is called http.jsm
> (lowercase) while in SeaMonkey 2.22 there's Http.jsm (uppercase) so that may
> be a problem?
Thunderbird 15 - Thunderbird 24 included a file called "http.jsm" which was originally from the chat code. I moved this into toolkit code in Thunderbird/Firefox 25 and renamed it to "Http.jsm". Versions of SeaMonkey using Gecko >=25 should have this file in it.

Lightning started using this file ("http.jsm") for the version that was released with Thunderbird 24. I updated Lightning to use the new version ("Http.jsm") for whatever version was compatible with Thunderbird 25.

All references in comm-release are to "Http.jsm", not "http.jsm": http://mxr.mozilla.org/comm-release/search?string=http.jsm

If you have more questions about what that is, I'd suggest coming on IRC to talk to me about what I did. I'm in #maildev and #instantbird almost always.

This bug is about OAuth CalDAV for Google Calendar working in SeaMonkey 2.21. Someone has decided that this will not be fixed as SeaMonkey 2.22 is out. We should probably stop using this bug and just ensure everything works in 2.22 (which seems to be bug 901332).
You need to log in before you can comment on or make changes to this bug.