Event/Todo creations and modifications displayed at next reload only

RESOLVED INCOMPLETE

Status

Calendar
Provider: CalDAV
RESOLVED INCOMPLETE
10 years ago
9 years ago

People

(Reporter: Bernard Desruisseaux, Unassigned)

Tracking

Details

(Reporter)

Description

10 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.13) Gecko/20080311 Firefox/2.0.0.13
Build Identifier: Lightning 0.8 w/ Thunderbird 2.0.0.12

Events and to-dos creations and modifications are displayed at the next
reload only in Mozilla Lightning 0.8 when the two following Add-ons are
both installed in Mozilla Thunderbird:

- xmpp4moz
  https://addons.mozilla.org/en-US/thunderbird/addon/3632

- SamePlace Instant Messenger
  https://addons.mozilla.org/en-US/thunderbird/addon/3633

After an event or to-do creation/modification Mozilla Lightning 0.8 tries to
download the created/modified event/to-do from the server with a
CALDAV:calendar-query REPORT searching for the component based on its UID
value.

When the aforementioned Add-ons are installed, the CALDAV:calendar-query
REPORT is corrupted as follows:

<?xml version="1.0" encoding="UTF-8"?>
<calendar-query xmlns:D="DAV:"
xmlns="urn:ietf:params:xml:ns:caldav"><D:prop><D:getetag/><calendar-data/></D:
prop><filter><comp-filter name="VCALENDAR"><comp-filter
name="VEVENT"><prop-filter name="UID"><text-match collation="i;octet">
                      e4bf8b9d-55c9-478e-8211-136e160078e5

</text-match></prop-filter></comp-filter></comp-filter></filter></calendar-que
ry>

That is, the UID value specified in the <text-match> element is prefixed and
suffixed by multiple white spaces.

As a consequence, the CalDAV server doesn't return any calendar object
resource to the CalDAV client, and the CalDAV client will only display the
creation/modification the next time it performs a reload of the calendar.

Reproducible: Always

Steps to Reproduce:
1. Install the "xmpp4moz" and "SamePlace Instant Messenger" add-ons.
2. Create an event or a to-do in a calendar hosted on a CalDAV server.

Actual Results:  
Event or to-do doesn't appear in the view, but the next time the calendar is refreshed, or that I click on the Reload button, the event or to-do will appear.

Expected Results:  
Event or to-do should have appeared in the view right after the creation or modification.

I tried the following sequence:

1- Installed xmpp4moz.
2- Unable to reproduche issue.
3- Installed SamePlace Instant Messenger.
4- Was able to reproduce issue.
5- Uninstalled SamePlace Instant Messenger.
6- Was still able to reproduce issue.
7- Uninstalled xmpp4moz.
8- Unable to reproduche issue.

Comment 1

10 years ago
From calDavCalendar.js:

700         queryXml =
701           <calendar-query xmlns:D="DAV:">
702             <D:prop>
703               <D:getetag/>
704               <calendar-data/>
705             </D:prop>
706             <filter>
707               <comp-filter name="VCALENDAR">
708                 <comp-filter name={itemType}>
709                   <prop-filter name="UID">
710                     <text-match collation="i;octet">
711                       {aItem.id}
712                     </text-match>
713                   </prop-filter>
714                 </comp-filter>
715               </comp-filter>
716             </filter>
717           </calendar-query>;

So the extra spaces are there in the first place.  Probably they're normally collapsed because of a XML.ignoreWhitespace = true somewhere, while xmpp4moz is doing XML.ignoreWhitespace = false.  Although that doesn't explain why two XML.ignoreWhitespace in different scopes would clash.

Comment 2

9 years ago
I think this bug should be closed because the caldav provider now does a multiget instead of a fetch by uid. And the multiget query is correctly created without extra spaces.

                var locpath = itemsNeedFetching.pop().toString();
                multigetQueryXml.D::prop += <D:href xmlns:D={D}>{locpath}</D:href>;
After talking to Philipp over IRC, he agreed to close this bug as INCOMPLETE.

Bernhard, if you can test with a Lightning 1.0pre nightly, this would be great, and we can change the resolution to WORKSFORME afterward.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.