365641 - CalDav Event intermittently disappears from Day View or Week View

Status: RESOLVED WORKSFORME

(Calendar :: Provider: CalDAV, defect)

Description

[notas]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; de; rv:1.8.1) Gecko/20060601 Firefox/2.0 (Ubuntu-edgy)
Build Identifier: 2007010203

After creating a new remote CalDav Calendar I added a new event. It was shown in month and week view, but not on day view.

I used the server provided for testing day 02012007:
http://mozilla.kewis.ch:8080/cosmo/home/calendar/Cosmo

Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Actual Results:  
The created event was not shown in the day view

Expected Results:  
display the event in the day view

Comment 1

[cmtalbert]

This is an exceptionally intermittent bug.  I cannot find a certain way to reproduce it, and when it does happen, it will usually correct itself after a few moments.  Here are the steps I followed using Sunbird.

Sunbird Build String: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a2pre) Gecko/20070102 Calendar/0.4a1 

BuildID: 2007010203

OS: Mac OS X 10.4.8

Using the same caldav server as above I followed these steps:
1. Sunbird and Operating system set to America/Chicago Timezone
2. Subscribed to the CalDav Server using the "New Calendar" dialog.
3. From month view, created an event within my GMT shadow (i.e. 0500).
4. Switched to Week View or Day View to see the new event.

Sometimes, the new event will not show up in day view or week view.

I've also managed to get this to happen with existing events by scrolling through the weeks on the week view.  

If the event is not displayed in week view, it will be displayed in Day view.  And if it is not displayed in Day view, it will be displayed in week view.  

This does NOT seem to happen if the event is the currently selected event.

After a few minutes (less than 5) of clicking on various views, the event will show up.  

It seems to be easiest to reproduce this using a clean profile and just after you have created the calendar.  Once it starts to work, it is much harder to get it to fail again, but I managed to do it once.

In light of all this, I am going to change the summary and confirm this bug.

Comment 2

[cmtalbert]

On closer inspection, I wonder if this is a duplicate of bug 355270?

Comment 3

[Bruno Browning]

I haven't been able to reproduce this, possibly because I tend to be on the same subnet as my CalDAV server (the comment about correcting itself after a few moments makes me suspect network latency issues). 

Granted that bug 355270 is "various problems", my understanding of the main problem being dealt with there is that the CalDAV provider doesn't properly error on bad (including non-CalDAV) URIs. That may be the case for the original reporter in this bug, but I doubt it's what is going on in comment #2, since if the calendar URI is bad you should see no events after a view change.

Comment 4

[Bruno Browning]

I'm seeing this now, too. I have a profile with three CalDAV calendars (Cosmo, Darwin, and RSCDS) and typically on startup the contents of only one of them (first to return query?) will appear in the UI. Clicking on any of the View buttons will cause the contents of all three calendars to appear in the UI. A dump() in reportInternal.onOperationDetail seems to indicate that the provider is passing items back to the listener's onGetResult which are for whatever reason not displayed.

Comment 5

[Bruno Browning]

Attachment: log itemcounts returned by CalDAV, ICS providers

I applied this trivial patch to a recent (post-0.5) Sb nightly and verified that the CalDAV provider, at least, is fetching items and passing them back to the views where they are often not displayed.

Running this in a profile with calendar.debug.log=true, I noticed that (only) on shutdown (and only in the xterm where Sb was run, since the error console has already been shut down) Sb throws multiple instances of:

reportInternal's onGetResult threw an exception [Exception...
"'[JavaScript Error: "Components is not defined" {file:
"chrome://calendar/content/calendar-month-view.xml" line: 1506}]' when
calling method: [calIOperationListener::onGetResult]"  nsresult:
"0x80570021 (NS_ERROR_XPC_JAVASCRIPT_ERROR_WITH_DETAILS)"  location: "JS
frame ::
file:///home/bruno/dloads/sunbird/components/calCompositeCalendar.js ::
anonymous :: line 483"  data: yes]; ignoring

Have seen similar "Components is not defined" errors against calendar-minimonth-busy.js under the same circumstances as well.

Comment 6

[Stefan Sitter [:ssitter]]

Does the issue still exists using a recent 0.8pre nightly build?

Comment 7

[Bruno Browning]

I've never been able to reproduce reliably the problem as originally described, nor the behavior described in comment #1. My rigorous "click around for a while in day and week view" bugtesting methodology failed to make the bug appear just now.

I definitely no longer see anything like what I described in comment #4, nor the errors on quit described in comment #5.

I see no reason to relnote this bug for 0.8. I haven't closed it yet because I do most of my testing in month view. Will switch to using week view for a while, and if this doesn't show up soon (or someone else chime in that they still see it) will close it.

Comment 8

[Philipp Kewisch [:Fallen][📱📆]]

Resolving WFM for now, Bruno (or anyone else), if you still experience this please reopen.