486773 - Ambiguous error - "Failed to parse item:"

Status: NEW

(Calendar :: Provider: CalDAV, defect)

Description

[aapthorp]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-GB; rv:1.8.1.6) Gecko/20070725 Firefox/2.0.0.6
Build Identifier: Lightning 1.0 pre 20090403

The error message "Failed to parse item:" is ambiguous and does not help detect th e source of the error. This error message is raised in two places and does not detail the cause of specific parsing problem.

This error is consistently logged when parsing certain but not all CalDav response (VTODO) items. The failed items are successfully parsed in Lightning 0.9.

Reproducible: Always

Steps to Reproduce:
1.Configure lightning to retrieve CalDav calendar
2.Error can be observed in error console as lightning loads calendar from CalDav server.
Actual Results:  
Example response:

Warning: Failed to parse item: <D:response xmlns:C="urn:ietf:params:xml:ns:caldav" xmlns:D="DAV:">
  <D:href>http://localhost:8080/taskcal-dav/user/calendar/tasks/62.ics</D:href>
  <D:propstat>
    <D:prop>
      <D:getetag>"20090222T112344-62"</D:getetag>
      <C:calendar-data>BEGIN:VCALENDAR
PRODID:-//aapthorp//jBPM iCal wrapper//EN
VERSION:2.0
CALSCALE:GREGORIAN
BEGIN:VTODO
DTSTAMP:20090403T215123Z
DTSTART;TZID=Europe/Prague:20090225T120000
DUE;TZID=Europe/Prague:20090225T160000
SUMMARY:collect shipment - 62
CREATED:20090222T102248Z
STATUS:NEEDS-ACTION
ATTACH:http://localhost:8080/jbpm-console/sa/task.jsf?id=62
LOCATION:Somewhere
LAST-MODIFIED:20090222T112344
CONTACT:someone
UID:20090222T102248Z-62@LEONARDO
PRIORITY:3
DESCRIPTION:Task 'collect shipment' has been assigned to you. It's due at 2
 5/02/2009 16:00 so go for it: 62 Thanks.
CATEGORIES:collect shipment
ATTACH;ENCODING=BASE64;VALUE=BINARY;FMTTYPE=text/html:PEhUTUw+PEJPRFk+PFBSR
 SBzdHlsZT0iZm9udC1mYW1pbHk6IG1vbm9zcGFjZTsgZm9udC1zaXplOiAxNHB4Ij48aHRtbDp
 0YWJsZSBib3JkZXI9IjEiIGNlbGxwYWRkaW5nPSIyIiBjZWxsc3BhY2luZz0iMiIgd2lkdGg9I
 jEwMCUiPjxodG1sOnRib2R5PjxodG1sOnRyPjxodG1sOnRkIHZhbGlnbj0idG9wIj5UaW1lPC9
 odG1sOnRkPjxodG1sOnRkIHZhbGlnbj0idG9wIj48aHRtbDppbnB1dCB0eXBlPSJ0ZXh0IiBuY
 W1lPSJUaW1lIiB2YWx1ZT0iMTY6MDAiIC8+PGh0bWw6YnIgLz48L2h0bWw6dGQ+PC9odG1sOnR
 yPjxodG1sOnRyPjxodG1sOnRkIHZhbGlnbj0idG9wIj5CZWdpbkRhdGU8L2h0bWw6dGQ+PGh0b
 Ww6dGQgdmFsaWduPSJ0b3AiPjxodG1sOmlucHV0IHR5cGU9InRleHQiIG5hbWU9IkJlZ2luRGF
 0ZSIgdmFsdWU9IjI1LzAyLzIwMDkiIC8+PGh0bWw6YnIgLz48L2h0bWw6dGQ+PC9odG1sOnRyP
 jxodG1sOnRyPjxodG1sOnRkIHZhbGlnbj0idG9wIj5CZWdpblRpbWU8L2h0bWw6dGQ+PGh0bWw
 6dGQgdmFsaWduPSJ0b3AiPjxodG1sOmlucHV0IHR5cGU9InRleHQiIG5hbWU9IkJlZ2luVGltZ
 SIgdmFsdWU9IjEyOjAwIiAvPjxodG1sOmJyIC8+PC9odG1sOnRkPjwvaHRtbDp0cj48aHRtbDp
 0cj48aHRtbDp0ZCB2YWxpZ249InRvcCI+QzpDTjwvaHRtbDp0ZD48aHRtbDp0ZCB2YWxpZ249I
 nRvcCI+PGh0bWw6aW5wdXQgdHlwZT0idGV4dCIgbmFtZT0iQzpDTiIgdmFsdWU9IkNOPWRhZGR
 5IiAvPjxodG1sOmJyIC8+PC9odG1sOnRkPjwvaHRtbDp0cj48aHRtbDp0cj48aHRtbDp0ZCB2Y
 WxpZ249InRvcCI+RGF0ZTwvaHRtbDp0ZD48aHRtbDp0ZCB2YWxpZ249InRvcCI+PGh0bWw6aW5
 wdXQgdHlwZT0idGV4dCIgbmFtZT0iRGF0ZSIgdmFsdWU9IjI1LzAyLzIwMDkiIC8+PGh0bWw6Y
 nIgLz48L2h0bWw6dGQ+PC9odG1sOnRyPjxodG1sOnRyPjxodG1sOnRkIHZhbGlnbj0idG9wIj5
 DOkxBU1QtTU9ESUZJRUQ8L2h0bWw6dGQ+PGh0bWw6dGQgdmFsaWduPSJ0b3AiPjxodG1sOmluc
 HV0IHR5cGU9InRleHQiIG5hbWU9IkM6TEFTVC1NT0RJRklFRCIgdmFsdWU9IjIwMDkwMjIyVDE
 wMjMzN1oiIC8+PGh0bWw6YnIgLz48L2h0bWw6dGQ+PC9odG1sOnRyPjxodG1sOnRyPjxodG1sO
 nRkIHZhbGlnbj0idG9wIj5DOkxPQ0FUSU9OPC9odG1sOnRkPjxodG1sOnRkIHZhbGlnbj0idG9
 wIj48aHRtbDppbnB1dCB0eXBlPSJ0ZXh0IiBuYW1lPSJDOkxPQ0FUSU9OIiB2YWx1ZT0iUm96Y
 XJjaW5hIiAvPjxodG1sOmJyIC8+PC9odG1sOnRkPjwvaHRtbDp0cj48aHRtbDp0cj48aHRtbDp
 0ZCB2YWxpZ249InRvcCI+QzpQQVJUU1RBVDwvaHRtbDp0ZD48aHRtbDp0ZCB2YWxpZ249InRvc
 CI+PGh0bWw6aW5wdXQgdHlwZT0idGV4dCIgbmFtZT0iQzpQQVJUU1RBVCIgdmFsdWU9Ik5FRUR
 TLUFDVElPTiIgLz48aHRtbDpiciAvPjwvaHRtbDp0ZD48L2h0bWw6dHI+PGh0bWw6dHI+PGh0b
 Ww6dGQgdmFsaWduPSJ0b3AiPkM6Q09OVEFDVDwvaHRtbDp0ZD48aHRtbDp0ZCB2YWxpZ249InR
 vcCI+PGh0bWw6aW5wdXQgdHlwZT0idGV4dCIgbmFtZT0iQzpDT05UQUNUIiB2YWx1ZT0iQWRya
 WFuIiAvPjxodG1sOmJyIC8+PC9odG1sOnRkPjwvaHRtbDp0cj48aHRtbDp0cj48aHRtbDp0ZCB
 2YWxpZ249InRvcCI+QzpEVFNUQVJUPC9odG1sOnRkPjxodG1sOnRkIHZhbGlnbj0idG9wIj48a
 HRtbDppbnB1dCB0eXBlPSJ0ZXh0IiBuYW1lPSJDOkRUU1RBUlQiIHZhbHVlPSIyMDA5LTAyLTI
 1IDEyOjAwOjAwLjAiIC8+PGh0bWw6YnIgLz48L2h0bWw6dGQ+PC9odG1sOnRyPjwvaHRtbDp0Y
 m9keT48L2h0bWw6dGFibGU+PC9QUkU+PC9CT0RZPjwvSFRNTD4=
ORGANIZER:MAILTO:[e-mail]
URL:http://localhost:8080/taskcal-dav/user/calendar/tasks/62.ics
ATTENDEE;CN=user;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:MAIL
 TO:[e-mail]
END:VTODO
END:VCALENDAR</C:calendar-data>
    </D:prop>
    <D:status>HTTP/1.1 200 OK</D:status>
  </D:propstat>
</D:response>

Expected Results:  
Item should be successully parsed as it is with Lightning 0.9.

Comment 1

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

Theoretically, an event that fails to parse (i.e throws an exception there) should cause 0.9 to stop parsing any further events. The error message you are getting happens when the ics parser can't parse the vcalendar. Not quite sure why this happes yet. The validator at http://severinghaus.org/projects/icv/ says the file is valid as soon as you remove the two ATTACH properties (but thats likely a bug in the validator). Saving that snippet as an ICS file and loading in lightning works for me, so I'm not quite sure yet why this fails in caldav.

One thing I noticed is that a timezone is referenced (Europe/Prague), but the calendar-data doesn't provide a timezone definition for Europe/Prague.

Comment 2

[Stefan Sitter [:ssitter]]

Trying to import only the iCalendar part into storage calendar fails with:

Error: DB error: not an error
exc: TypeError: att.uri is null

Error: Import error: [Exception... "'[JavaScript Error: "att.uri is null" {file: "file:///E:/sunbird/calendar-js/calStorageCalendar.js" line: 2699}]' when calling method: [calICalendar::addItem]"  nsresult: "0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS frame :: chrome://calendar/content/import-export.js :: putItemsIntoCal :: line 205"  data: yes]
Source File: chrome://calendar/content/import-export.js Line: 213

Maybe caldav providers encounters a similar error or the same error if storage provider (experimental cache feature?) is involved?

Comment 3

[Stefan Sitter [:ssitter]]

Reporter, have you enabled the experimental cache feature for the calendar? 
If yes I'd like you to retest with disabled cache.

Comment 4

[Daniel Boelzle [:dbo]]

Attachment: [checked in] graceful import

At least the import problem mentioned in comment #2 looks like a code bug: We yet don't support inline attachments, and should be graceful when importing (filtering those out).

Comment 5

[aapthorp]

To <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=486773#c3">comment #3</a>, no the cache is disabled.

To <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=486773#c1">comment #1</a>, this item is the same structure of ones that parse OK including the timezone issue.

When I look at the source this error message can be logged for two different errors (hence original bug report). I'm assuming it's the parser error and not the issue with number of items.

Comment 6

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

Comment on attachment 371145 [details] [diff] [review]
[checked in] graceful import

>diff --git a/calendar/base/src/calItemBase.js b/calendar/base/src/calItemBase.js
>--- a/calendar/base/src/calItemBase.js
>+++ b/calendar/base/src/calItemBase.js
>@@ -522,7 +522,7 @@ calItemBase.prototype = {
>     removeAttachment: function cIB_removeAttachment(aAttachment) {
>         this.modify();
>         for (var attIndex in this.mAttachments) {
>-            if (this.mAttachments[attIndex].uri.spec == aAttachment.uri.spec) {
>+            if (cal.compareObjects(mAttachments[attIndex], aAttachment, Components.interfaces.calIAttachment)) {
Do we really want to compare the whole object? I thought maybe the uri should be unique?


>-                ap.data = att.uri.spec;
>+                ap.data = (att.uri ? att.uri.spec : "");
Possibly we want to set null here instead of an empty string? Or does the round trip work out with empty string?

r=philipp with comments considered.

Comment 7

[Daniel Boelzle [:dbo]]

AFAIK the uri is optional, so we cannot compare those. Moreover IIRC having multiple identical attachments is valid.

Comment 8

[Daniel Boelzle [:dbo]]

> (From update of attachment 371145 [details] [diff] [review])
> >diff --git a/calendar/base/src/calItemBase.js b/calendar/base/src/calItemBase.js
> >--- a/calendar/base/src/calItemBase.js
> >+++ b/calendar/base/src/calItemBase.js
> >@@ -522,7 +522,7 @@ calItemBase.prototype = {
> >     removeAttachment: function cIB_removeAttachment(aAttachment) {
> >         this.modify();
> >         for (var attIndex in this.mAttachments) {
> >-            if (this.mAttachments[attIndex].uri.spec == aAttachment.uri.spec) {
> >+            if (cal.compareObjects(mAttachments[attIndex], aAttachment, Components.interfaces.calIAttachment)) {
> Do we really want to compare the whole object? I thought maybe the uri should
> be unique?
compareObjects just compare the js references. Since multiple identical attachments may occur, this is the only valid way IMO.


Pushed to comm-central <http://hg.mozilla.org/comm-central/rev/c429f29cf483>

-> FIXED(In reply to comment #6)

This is just a bugfix to import inline attachments gracefully. There's still no overall support for inline attachments.

Comment 9

[aapthorp]

I am still observing the same problem. So don't think it is fixed

Comment 10

[Martin Schröder [:mschroeder]]

There (In reply to comment #9)
> I am still observing the same problem. So don't think it is fixed

Please leave the resolution as is ('FIXED') or REOPEN the bug report. What version of Lightning did you use to reproduce the original problem?

Comment 11

[aapthorp]

And how does one REOPEN the bug report? I thought that was what I was doing.

I tested with the 26th April nightly. As per my original report this problem doesn't happen on all VTODOs with similar properties. i.e. many with attachments are handled successfully.

Comment 12

[Martin Schröder [:mschroeder]]

(In reply to comment #11)
> And how does one REOPEN the bug report? I thought that was what I was doing.

Sorry, this feature of Bugzilla has changed recently.

Comment 13

[Daniel Boelzle [:dbo]]

Philipp, don't we already have a bug for inline attachment support?

(In reply to comment #9)
> I am still observing the same problem. So don't think it is fixed
still the same error message?

Comment 14

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

(In reply to comment #13)
> Philipp, don't we already have a bug for inline attachment support?

This should be bug 168680

Comment 15

[Stefan Sitter [:ssitter]]

(In reply to comment #2)
> Trying to import only the iCalendar part into storage calendar fails with:
> Error: DB error: not an error exc: TypeError: att.uri is null

I can confirm that this import error is gone using Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1.1pre) Gecko/20090703 Calendar/1.0pre.

Comment 16

[Martin Schröder [:mschroeder]]

Reporter (aapthorp), can you please try to reproduce the problem in a recent Lightning 1.0pre nightly build, and report back if this has also been fixed for you?

Comment 17

[aapthorp]

I've just tested with Mozilla/5.0 (X11; U;Linux i686; en-US; rv:1.9.1.b3pre) Gecko/20090223 Calendar/1.0pre build id 20090710040317 and found an example of when this fails. Admittedly there are some other errors but without the attachment it is parsed successfully and with it fails.

The error only seems to occur in a few special cases now, such as this, but is parsed successfully in 0.9.

This (without attachment) parses successfully:

<D:response>
<D:href>http://LEONARDO:8080/taskcal-dav/manager/calendar/tasks/89776152-f6db-4920-8c16-f4ecb79412b4.ics</D:href>
<D:propstat>
<D:prop>
<D:getetag>"20090704T152434Z-188"</D:getetag>
<C:calendar-data>BEGIN:VCALENDAR
PRODID:-//aapthorp//jBPM iCal wrapper//EN
VERSION:2.0
CALSCALE:GREGORIAN
BEGIN:VTODO
DTSTAMP:20090711T074942Z
DTSTART:
DUE:
SUMMARY:Create Booking - 188
CREATED:20090704T152434Z
STATUS:NEEDS-ACTION
ATTACH:http://LEONARDO:8080/jbpm-console/sa/task.jsf?id=188
UID:89776152-f6db-4920-8c16-f4ecb79412b4
PRIORITY:3
DESCRIPTION:
CATEGORIES:Create Booking
ORGANIZER:MAILTO:jbpm@noreply
URL:http://LEONARDO:8080/taskcal-dav/manager/calendar/tasks/89776152-f6db-4
 920-8c16-f4ecb79412b4.ics
LAST-MODIFIED:20090704T152434Z
ATTENDEE;CN=manager;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:MA
 ILTO:[e-mail]
END:VTODO
END:VCALENDAR
</C:calendar-data>
</D:prop>
<D:status>HTTP/1.1 200 OK</D:status>
</D:propstat>
</D:response>
</D:multistatus>

This (with attachment) doesn't parse successfully:


Warning: Failed to parse item: <D:response xmlns:D="DAV:" xmlns:C="urn:ietf:params:xml:ns:caldav">
  <D:href>http://LEONARDO:8080/taskcal-dav/manager/calendar/tasks/89776152-f6db-4920-8c16-f4ecb79412b4.ics</D:href>
  <D:propstat>
    <D:prop>
      <D:getetag>"20090704T152434Z-188"</D:getetag>
      <C:calendar-data>BEGIN:VCALENDAR
PRODID:-//aapthorp//jBPM iCal wrapper//EN
VERSION:2.0
CALSCALE:GREGORIAN
BEGIN:VTODO
DTSTAMP:20090711T075551Z
DTSTART:
DUE:
SUMMARY:Create Booking - 188
CREATED:20090704T152434Z
STATUS:NEEDS-ACTION
ATTACH:http://LEONARDO:8080/jbpm-console/sa/task.jsf?id=188
UID:89776152-f6db-4920-8c16-f4ecb79412b4
PRIORITY:3
DESCRIPTION:
CATEGORIES:Create Booking
ATTACH;ENCODING=BASE64;VALUE=BINARY;FMTTYPE=text/html:PEhUTUw+DQo8Qk9EWT4NC
 jxQUkUgc3R5bGU9ImZvbnQtZmFtaWx5OiBtb25vc3BhY2U7IGZvbnQtc2l6ZTogMTJweCI+DQo
 8aHRtbDp0YWJsZSBib3JkZXI9IjEiIGNlbGxwYWRkaW5nPSIyIiBjZWxsc3BhY2luZz0iMiIgd
 2lkdGg9IjEwMCUiPjxodG1sOnRib2R5Pg0KPGh0bWw6dHI+DQoJPGh0bWw6dGQgdmFsaWduPSJ
 0b3AiPkM6VUlEPC9odG1sOnRkPg0KCTxodG1sOnRkIHZhbGlnbj0idG9wIj48aHRtbDppbnB1d
 CB0eXBlPSJ0ZXh0IiBuYW1lPSJDOlVJRCIgdmFsdWU9Ijg5Nzc2MTUyLWY2ZGItNDkyMC04YzE
 2LWY0ZWNiNzk0MTJiNCIvPg0KCTxodG1sOmJyIC8+DQoJPC9odG1sOnRkPg0KPC9odG1sOnRyP
 g0KPGh0bWw6dHI+DQoJPGh0bWw6dGQgdmFsaWduPSJ0b3AiPkM6UEFSVFNUQVQ8L2h0bWw6dGQ
 +DQoJPGh0bWw6dGQgdmFsaWduPSJ0b3AiPjxodG1sOmlucHV0IHR5cGU9InRleHQiIG5hbWU9I
 kM6UEFSVFNUQVQiIHZhbHVlPSJORUVEUy1BQ1RJT04iLz4NCgk8aHRtbDpiciAvPg0KCTwvaHR
 tbDp0ZD4NCjwvaHRtbDp0cj4NCjxodG1sOnRyPg0KCTxodG1sOnRkIHZhbGlnbj0idG9wIj5DO
 kRUU1RBUlQ8L2h0bWw6dGQ+DQoJPGh0bWw6dGQgdmFsaWduPSJ0b3AiPjxodG1sOmlucHV0IHR
 5cGU9InRleHQiIG5hbWU9IkM6RFRTVEFSVCIgdmFsdWU9IiR2YXJNYXAuZ2V0KCRrZXkpIi8+D
 QoJPGh0bWw6YnIgLz4NCgk8L2h0bWw6dGQ+DQo8L2h0bWw6dHI+DQo8L2h0bWw6dGJvZHk+PC9
 odG1sOnRhYmxlPg0KPC9QUkU+DQo8L0JPRFk+DQo8L0hUTUw+
ORGANIZER:MAILTO:jbpm@noreply
URL:http://LEONARDO:8080/taskcal-dav/manager/calendar/tasks/89776152-f6db-4
 920-8c16-f4ecb79412b4.ics
LAST-MODIFIED:20090704T152434Z
ATTENDEE;CN=manager;PARTSTAT=NEEDS-ACTION;ROLE=REQ-PARTICIPANT;RSVP=TRUE:MA
 ILTO:[e-mail]
END:VTODO
END:VCALENDAR</C:calendar-data>
    </D:prop>
    <D:status>HTTP/1.1 200 OK</D:status>
  </D:propstat>
</D:response>

Comment 18

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

These bugs are likely targeted at Lightning 1.0b1, not Lightning 1.0. If this change was done in error, please adjust the target milestone to its correct value. To filter on this bugspam, you can use "lightning-10-target-move".