608709 - Can't create/connect calendar using Provider for Google Calendar extension

Status: RESOLVED FIXED

(Calendar :: Provider: GData, defect)

Description

[Lumir Navrat]

User-Agent:       Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101026 Firefox/4.0b8pre SeaMonkey/2.1b2pre
Build Identifier: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b8pre) Gecko/20101026 Firefox/4.0b8pre SeaMonkey/2.1b2pre

When open Event & Calendar task I'got this error message. Same message is shown, when try to create new calendar. I think, that it's problem with provider, because attempt to create local calendar was ok.

It doesn't depend on instalation type. It's same in this case:

1. daily nightly updates
   a) delete all data from lightning.
   b) standard update procedure
2. fresh installation of all components (Seamonkey, Lightning, GProvider)


[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:///D:/Users/nav79/AppData/Roaming/Mozilla/SeaMonkey/Profiles/rywitzlb.default/extensions/%7Be2fda1a4-762b-4020-b5ad-a41df1933103%7D/calendar-js/calCalendarManager.js :: cmgr_createCalendar :: line 580"  data: no]

Reproducible: Always




This error is shown from august/september.

It was generated on Windows 7 64bit and Windows XP 32 bit.

Comment 1

[Lumir Navrat]

Today i found, that can use CalDAV protocol, and this protokol works. So it's must be problem in GProvider with Seamonkey.

Comment 2

[Stefan Sitter [:ssitter]]

Confirmed using Lightning 1.1a1pre (20101104) with Thunderbird 3.3a1pre. Adding <em:unpack>true</em:unpack> to install.rdf seems to fix the problem.

Comment 3

[Stefan Sitter [:ssitter]]

Attachment: [checked in] force xpi unpacking

Comment 4

[Martin Schröder [:mschroeder]]

Comment on attachment 488253 [details] [diff] [review]
[checked in] force xpi unpacking

I can't r+ this patch without knowing the reason why we need to unpack to make it work.

Comment 5

[Lumir Navrat]

Yes, this "hack" work :) Nice, because GProvider is faster then CalDav:)

Comment 6

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

I too wonder why we need to unpack. The Provider doesn't use any binary components, so it should be fine. I'll have to look into this more closely.

Comment 7

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Backported to comm-1.9.2 <http://hg.mozilla.org/releases/comm-1.9.2/rev/8b47e5525023>

a=philipp

Comment 8

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Sorry, wrong window! This bug was of course not backported!

Comment 10

[Mark Banner (:standard8)]

As I said in bug 621138, my suspicion would be that chrome.manifest needs to reference the javascript component rather than referencing the manifest file in the same directory.

Personally, I'd rather have a working nightly build with reduced startup perf and a blocking bug on fixing it, than a completely not working nightly build.

Comment 11

[Martin Schröder [:mschroeder]]

Comment on attachment 488253 [details] [diff] [review]
[checked in] force xpi unpacking

r=mschroeder for this temporary workaround fix

Comment 12

[Mark Banner (:standard8)]

Comment on attachment 488253 [details] [diff] [review]
[checked in] force xpi unpacking

Checked in: http://hg.mozilla.org/comm-central/rev/07819e112e69

Leaving open for resolution of the main issue (unless we want to move that to a different bug).

Comment 13

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

The performance win is minimal, so I think we can just stay with unpacking the xpi. Thanks for finding out why it was going wrong!