393387 - week view is blank

Status: VERIFIED FIXED

(Calendar :: Calendar Frontend, defect)

Description

[Ulf Stroehler]

User-Agent:       Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.8.1.6) Gecko/20070731 Firefox/2.0.0.6
Build Identifier: Mozilla/5.0 (X11; U; SunOS i86pc; en-US; rv:1.8.1.6) Gecko/20070802 Thunderbird/2.0.0.6 ID:2007080210 - Lightning version 0.7.9.2007082202

after some time working with current Lightning nightly build the week view is blank. Means no event of any calendar is displayed at all in week view. All providers seem to be affected.

Day view seems to work.

Unfortunately we don't seem to find anything appropriate in the Error Console displayed.

Reproducible: Sometimes

Steps to Reproduce:
Unfortunately there is no bullet proof way to reproduce but we have a number of users with multiple incidents showing this problem

1. press reload all remote calendars
2. switch to another week
3. hit 'go to today' button
Actual Results:  
Week view is completely empty

Expected Results:  
Week view should display all events at the appropriate date/time

Comment 1

[Ulf Stroehler]

@daniel: as said this one should be blocking 0.7.

Comment 2

[Stefan Sitter [:ssitter]]

There are several bugs regarding this issue, search for Status Whiteboard: [0.5 disappearing events]. But we still don't have a clue what causes this.

Comment 3

[Daniel Boelzle [:dbo]]

We should spend time on this.

Comment 4

[Ulf Stroehler]

Alternative Steps to Reproduce:

This bug seems to happen during normal work with Thunderbird and Lightning and in conjunction with the new Mail and Calendar switches at the lower left in TB.
I can at least reproduce this bug on one system by toggling the Mail and Calendar switches. 
Having switched to Lightning and back to Mail and forth to Lightning the week view is empty.

Comment 5

[Daniel Boelzle [:dbo]]

Status of this bug:
I could reproduce the bug with respect to WCAP by cutting the connection after logon, e.g. via wrong proxy settings. I've debugged the problem and it seems that WCAP misses to send a final onOperationComplete under certain circumstances which I'm going to fix. That way, the composite calendar doesn't send a final onOperationComplete; already described in bug 394443. The views however won't process any further until an onOperationComplete has been received, see

<http://mxr.mozilla.org/mozilla1.8/search?string=mRefreshPending&find=calendar&findi=&filter=&tree=mozilla1.8>

I consider this fragile: However we could fix WCAP (and possibly ICS too), we
* have no influence on 3rd party providers(!)
* calendar requests are non-deterministic, what if a remote calendar takes 5 minutes to retrieve data?

It would be good to know why the views guard against multiple open requests.

For mid term, I suggest that we implement the calIOperation handles for async providers. That way the views could cancel a pending request before sending a new one. For short term, I am going to spend time on fixing the bug for ics, too.

Comment 6

[Stefan Sitter [:ssitter]]

This are the other bugs regarding this issue: 
<https://bugzilla.mozilla.org/buglist.cgi?quicksearch=0.5+disappearing+events>

Comment 7

[Daniel Boelzle [:dbo]]

(In reply to comment #5)
> It would be good to know why the views guard against multiple open requests.
Joey or Mickey, could you shed some light on this, please?

Comment 8

[Daniel Boelzle [:dbo]]

Attachment: ics: missing unlocks in case of error

Potentially unsafe code => leads to locked queue.

shifted from <https://bugzilla.mozilla.org/show_bug.cgi?id=387559#c41>

Comment 9

[Daniel Boelzle [:dbo]]

Attachment: distinguish canceled operation from operation error

IMO makes general sense; currently needed for WCAP only.

Comment 10

[Michael Büttner (no reviews TFN)]

(In reply to comment #7)
> (In reply to comment #5)
> > It would be good to know why the views guard against multiple open requests.
> Joey or Mickey, could you shed some light on this, please?
That's because the view refresh() operation wasn't reentrant, see [1]. There's also an explanation where's the problem and why a queue solves it.

[1] https://bugzilla.mozilla.org/show_bug.cgi?id=329035#c5

Comment 11

[Michael Büttner (no reviews TFN)]

Comment on attachment 280159 [details] [diff] [review]
ics: missing unlocks in case of error

no complaints, nicely spotted. r=mickey.

Comment 12

[Michael Büttner (no reviews TFN)]

Comment on attachment 280160 [details] [diff] [review]
distinguish canceled operation from operation error

r=mickey.

Comment 13

[Daniel Boelzle [:dbo]]

Checked in attached patches + WCAP fixes on HEAD and MOZILLA_1_8_BRANCH.

Comment 14

[Daniel Boelzle [:dbo]]

We're pretty confident that we've tracked down the problem at Ulf's computer and it turned out to be a slow proxy caused his problem. Thus there's are no more findings than I commented in comment #5: A pending calendar request effectively blocks the view from showing any other calendar. We agreed that implementing calIOperation for composite and ics is the right way. The views could then cancel the pending (composite) and immediately send out a new getItems call.

Comment 15

[Daniel Boelzle [:dbo]]

Attachment: calOperationGroup, views cancel pending operation, optimizing setDateRange/setDateList

- views cancel pending operations instead of waiting until they've benn completed
- implements an operation group used by composite calendar which cancels all sub operations and disconnects the composite listener once the operation has been cancelled
- optimizing unnecessary view refreshes by checking for changes in setDateRange/setDateList; caused by broadcasted onLoad (both unifinder-todo and composite calendar refresh the views)
- compareArrays() helper

Comment 16

[Michael Büttner (no reviews TFN)]

Daniel, this patch causes a message box to come up, telling me "OPERATION_CANCELLED". This is the well-known beloved WCAP error box, you probably know what I'm talking about. Of course this happens only if WCAP calendars have been configured.

Comment 17

[Daniel Boelzle [:dbo]]

(In reply to comment #16)
Update your tree, I've fixed that this afternoon.

Comment 18

[Daniel Boelzle [:dbo]]

Attachment: calOperationGroup, views cancel pending operation, optimizing setDateRange/setDateList

minor improvement

Comment 19

[Michael Büttner (no reviews TFN)]

Comment on attachment 280764 [details] [diff] [review]
calOperationGroup, views cancel pending operation, optimizing setDateRange/setDateList

I didn't find anything to complain about, the patch works like a charm -> r=mickey.

Comment 20

[Daniel Boelzle [:dbo]]

Checked in on HEAD and MOZILLA_1_8_BRANCH. I hope this fixes some of <https://bugzilla.mozilla.org/buglist.cgi?quicksearch=0.5+disappearing+events>, too.

Comment 21

[Andreas Treumann]

Verified in latest nightly 20080108 -> task is fixed.