Closed Bug 610152 Opened 11 years ago Closed 7 years ago

Events randomly disappear from the view pane. View returns when TB is restarted.

Categories

(Calendar :: Calendar Frontend, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: chris, Assigned: mmecca)

References

Details

Attachments

(3 files, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US) AppleWebKit/534.11 (KHTML, like Gecko) Chrome/9.0.570.1 Safari/534.11
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.12) Gecko/20101027 Lightning/1.0b2 Thunderbird/3.1.6

For some reason unknown to me, I often return to TB/Lightning and the calendar view is empty. My calendars are still shown, they are not flagged as read-only. 

Reproducible: Sometimes

Steps to Reproduce:
1. Look at lightning event pane
2. there are no events at all
3. restart TB/Lightning
4. events are back
Actual Results:  
All events randomly vanish from view

Expected Results:  
Events are always seen.

I have no idea what causes this, but if I leave TB running for a few hours/days, it will eventually happen, forcing me to restart to see my events again.
(In reply to comment #0)

I can confirm I see the same, or something very similar. On apparently random occations, the view pane will stop showing any events. The effect is limited to a particular view type, e.g. at this moment my 'Month' pane is emtpy, while the 'Multiweek' shows (all) events. The effect does spread to all views, eventually. It may take hours or days for the problem to manifest in any given view, and seems related to the 'amount of use' for the particular pane.

As per the original report, a restart fixes all problems temporarily.

A new event will show in the non-functional (empty) view, but disappears as soon as you scroll away (and back).

All except one of my calendars are on google, using google calendar provider 0.7.1. But also the local calendar does not show.

The error console does not show anything strange when switching between functional and non-functional (empty) views. I haven't been able to catch effect 'in the act' on the error console.

Details of my system:
Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.13) 
Gecko/20101208 
Lightning/1.0b2 
Thunderbird/3.1.7

Ubuntu Maverick (10.10) 2.6.35-24-generic
I can confirm this behaviour with the latest Lightning nightly v1.0b3pre 20110121032800.

I've subscribed to several ICS calendars. All events are initially shown after 
starting TB but after a while all events are vanishing from the views. I've checked the error console but no messages are shown at all. After restarting TB all events reappear again.

I'm not 100% sure but I think this effect started after I've installed the nightly 'lightning_1.0b3pre-tb3-win32_20110114'.

Details of my system:
Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.13)
Gecko/20101207
Lightning/1.0b3pre
Thunderbird/3.1.7
I can now confirm that everything works as expected again after installing the nightly 'lightning_1.0b3pre-tb3-win32_20110114'.
WFM per comment#3
Status: UNCONFIRMED → RESOLVED
Closed: 11 years ago
Resolution: --- → WORKSFORME
(In reply to comment #3)

> I can now confirm that everything works as expected again after installing
> the nightly 'lightning_1.0b3pre-tb3-win32_20110114'.

Shame on me, I've mistyped the version number. What I wanted to say is that
it worked again after I've installed the previous Lightning version v1.0.3pre-tb3-win32_20101226035530. Nevertheless I will give the latest nightly a try an will post the test result.
(In reply to comment #5)

> Shame on me, I've mistyped the version number. What I wanted to say is that
> it worked again after I've installed the previous Lightning version
> v1.0.3pre-tb3-win32_20101226035530. Nevertheless I will give the latest nightly
> a try an will post the test result.

I've just installed the latest nightly v1.0.3pre-tb3-win32_20110226033940 and the decribed effect is still the same. After a while, around 10-15min, all events vanished from the views and I had to restart TB again to let all events reappear.

Details of my system:
Mozilla/5.0 (Windows; U; Windows NT 6.0; de; rv:1.9.2.13) Gecko/20101207 Lightning/1.0b3pre Thunderbird/3.1.7
Status: RESOLVED → UNCONFIRMED
Resolution: WORKSFORME → ---
I've set 'calendar.debug.log = true' and also 'calendar.debug.log.verbose = true' but no messages at all are being logged when the events vanish. What else can I do to bring the root cause to light?
Could you try disabling (in the calendar properties, not just the checkbox) all but one ics calendar? It could be that one of the calendars not correctly loading is causing an error, which might stop events from showing.

Otherwise, next time this happens try unchecking all calendars (this time with the checkbox), then re-checking them one at a time.
Hello Philipp I followed your recommendation and disabled all calendars
and also disable 'Show Alarms'. Additionally I created a totally new
calendar with only five events, one per weekday. Then I restarted TB
and activated the new calendar file. After a while the events vanished
again without giving any notice about the root cause.
I tried to deactivate/activate and reload the calendar file but without
success. Once the following error message was displayed on the error console
but I couldn't prove that it's bound to the described scenario:

Error: uncaught exception: [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIExternalProtocolService.loadUrl]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)"  location: "JS frame :: chrome://communicator/content/contentAreaClick.js :: openLinkExternally :: line 188"  data: no]

Just another thought: As I described in a previous posting it seams to me that the behaviour of Lightning has changed between December 26th 2010 and January 14th 2011 (Lightning v1.0b3pre). Now I wonder if it would be possible to find out what exactly has been changed between these two versions.
> Now I wonder if it would be possible to find
> out what exactly has been changed between these two versions.

https://hg.mozilla.org/releases/comm-1.9.2/pushloghtml?startdate=2010-12-26+00:00:00&enddate=2011-01-14+23:59:59
So you are saying, it worked before December 26th? Could you narrow it down by trying different nightlys, between the pushes mentioned in the link Stefan posted? It might be interesting to see if it happened before or after Mon Jan 10 02:05:51 2011 -0800.

Remember that the fixes are contained in the nightly built just after the push, so the fix might not be in the Jan 10th nightly, but it will defintely be in the Jan 11th nightly.
As requested I've downloaded several nightly builds (comm-1.9.2) and installed
it one after the other. As far as I can see the nightly 20110109035353 works fine but the nightly 20110110035708 causes the described problem. I tested it twice with the same result.

It seems that everything points to the following patch: 

https://hg.mozilla.org/releases/comm-1.9.2/pushloghtml?startdate=2011-01-09+03%3A53%3A53&enddate=2011-01-10+03%3A57%3A08
Matthew, can you have a look at this bug? It seems bug 389281 has caused a regression.
@juergen.edner - are your calendar files stored on a local disk, network drive, or over http?

I haven't been able to reproduce this.
Hello Matthew, I'm accessing all calendar files over http/https.
I was able to reproduce this behavior once, and spent most of the day trying to reproduce it again but was never able to. Does this happen on every run for you? 

Also, are the refresh intervals on any of the calendars set to the same number of minutes as it takes for the events disappear? If you set the refresh interval to a lower setting like once per minute will the problem show up sooner?

Have you tested a current nightly build on a new clean thunderbird profile, and if so does the problem show up after the first http calendar is added, or only with several?
As requested I've set-up a new TB profile, installed the latest Lightning nightly 20110305 and added only one calendar file with five events in total and the default refresh interval of 30min. After 30min the events had vanished.

Then I changed the refresh interval to 5min and restarted TB. After further 5min the events had vanished again. After that I changed the refresh interval to 1min with the same effect. The events are vanishing from the screen exactly after the given refresh time.

If you have a patched Lightning version which includes more debug outputs etc. you can send it directly to me and would be more than happy to install and run it on my PC to get hold of the problem.
Maybe you can provide Matthew with access to a such calendar? Possibly its some interaction issue between that specific server and Lightning we need to fix.
(In reply to comment #17)

I've traced the http communication between TB and my Apache WevDAV-Share using Fiddle2 but I couldn't see any strange behaviour happen. The first access returns a "HTTP/1.1 200 OK" and the whole calendar file is transfered to the client and displayed properly. Further accesses are each returning "HTTP/1.1 304 Not Modified" without transfering any data. I've attached two screenshots showing the results.
Assignee: nobody → matthew.mecca
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I think there are 2 different bugs here causing similar results. 

One is the regression caused by bug 389281 with ICS files on Apache WebDAV that juergen.edner reported. 

The other one is what I experienced once but was never able to reproduce, and may be the cause of the issue originally reported in comment #0 and comment #1 that predates the fix to bug 389281. I still have not been able to reproduce it again, but it seemed related to the views, as the events were still showing in the unifinder.

I would suggest we keep this bug open in case we can find a way to reliably reproduce the original issue, and reopen bug 389281 to fix the regression - I will have a new patch for that shortly.
See also bug 610136 comment 4, a similar issue is reported there, the comment may lead to fixing this bug (thanks Torsten!)
Duplicate of this bug: 610136
Flags: blocking-calendar1.0+
Keywords: regression
Whiteboard: [needed beta][no l10n impact]
The regression fix was checked in with bug 389281. Please wait 24 hours and then retry the latest nightly build and report back. Thanks!
Latest nightly (12-Mar-2011 06:32 PST): Calendar entries are all shown after reloading the calendar files even if server answers with 304. Thank you very much for fixing this bug!
I've installed the nightly 20110312034501 and can confirm that the calendar events are not vanishing anymore. Very good work!
Marking fixed per previous comments, patch is in bug 389281.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago11 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0b3
Depends on: 389281
I'd suggest leaving this open due to the other (original) issue - see comment #22.
Ok, reopening for the original issue when it can be reproduced. Maybe we should consider adding more debug to the ics provider. I'm resetting the blocking flags until we have reliable steps to reproduce.
Status: RESOLVED → UNCONFIRMED
Ever confirmed: false
Flags: blocking-calendar1.0+
Keywords: regression
OS: Windows 7 → All
Hardware: x86 → All
Resolution: FIXED → ---
Whiteboard: [needed beta][no l10n impact]
Target Milestone: 1.0b3 → ---
Hello!

Though this may be somewhat out of scope, I can say I have been observing this type of behaviour on my old 0.9 version. The disappearing was not so random but on the contrary occured very constantly while trying to extend a "new event" scheduling window beyon the last visible time of day in a weekly view of events. The new event would not show in the window after completing the fill-up of information.
The correction had nearly to be the same as described above: for a constant correct view of all events, Sunbird had to be restarted. The "disappeared" events would though also show correctly when switching to another week and coming back, but this would not be completely permanent i.e. refreshing the screen on the target week could leave the event in status "disappeared" again.

Hope this helps.
PhL
I encountered a similar problem while adding a CalDAV calendar. All events were listed but not displayed in neither day, week, multiweek or month pane.

When adding an event in this state, it briefly showed in the pane as expected but disappeared after some milliseconds.

I'm using thunderbird 6 with lightning 1.05b on SuSE 11.4

After restarting thunderbird the events do show as expected and I can not recreate the problem by deleting and readding the calendar.
@mmecca: Do you still work on this one?
Status: UNCONFIRMED → ASSIGNED
Ever confirmed: true
I think this can be closed, there doesn't seem to be a reliable way to reproduce this currently. Marking back to FIXED per comment #28
Status: ASSIGNED → RESOLVED
Closed: 11 years ago10 years ago
Resolution: --- → FIXED
Target Milestone: --- → 1.0b3
It's not fixed, so you probably shouldn't mark it so. 

I still see this bug, including right now in TB11. 

I can't reliably reproduce the bug either, but it happens a few times a week. I think it has to do with thunderbird being on for several days. The symptoms are as I described in comment #0.
Resolution: FIXED → WONTFIX
Chris, are you also using an ICS calendar? (sorry if I missed this in the previous comments). Also, what other calendars are you subscribed to? Do you have the cache enabled on any of them?

Could you enable calendar.debug.log and calendar.debug.log in the advanced config editor at Options > Advanced > General > Config Editor, then wait for the issues to come up? You should now be getting some more debug messages, if this is an ICS calendar then prefixed with [calICSCalendar].

If this doesn't help, then maybe we need to add some more debug messages to the calendar views and the operation listeners.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
Chris, are you still seeing this, and if so are you able to get the debug messages as described in comment #36?
Whiteboard: [closeme 2012-11-01]
Thunderbird 18.0a2 2012-10-11; Lightning 2.0a2 BuildID=20121013174706

I've just seen this bug. It seems it occurred after I added a Google calendar (calDAV) with a wrong location (the calendar was not working) but I'm not too sure about the timing. Unfortunately I didn't have the preference calendar.debug.log enabled.
The funny thing is that at the moment I *can see* all the calendars' events when in *day* view, instead nothing is visible in any other view.
I also tried to enable/disable all the calendars and delete the Google calendar, but nothing has changed.
Now all the calendars are locals and no related messages appear in the console even with calendar.debug.log enabled, apart from the message "this.tree is null" due to bug 632174.
Now I'm able to reproduce it in this way, although I'm not completely sure if it's the same bug:

1. Start Thunderbird and select all the views one by one, then stay on any view;
2. create a new network calendar but with a wrong address. I create a Google calDAV calendar, something like 
https://www.google.com/calendar/dav/xxxxxx/events;
3. cancel the dialog that asks the user and password

-> the new network calendar get disabled and all the events disappear from all the views.


During step 1., if you don't select all the views, the events disappear only in the actual view and the views previously selected but are still visible in the other views.

The console reports only the error related to the calDAV calendar (calendar.debug.log enabled):

"CalDAV: Status 401 on initial PROPFIND for calendar g"
Severity: major → normal
Status: REOPENED → NEW
Whiteboard: [closeme 2012-11-01]
Target Milestone: 1.0b3 → ---
I suspect the problem may be similar to the one causing Bug 529771 in the task tree, the refresh queue can get stuck under certain conditions.
Attached patch base-view-refresh.diff (obsolete) — Splinter Review
Gets rid of the refresh queue in the views, which can become stuck and prevent further updates to the views if a getItems operation doesn't return properly. This also allows the views to better handle a refresh of multiple calendars at the same time.
Attachment #8496588 - Flags: review?(philipp)
Blocks: 1073982
Comment on attachment 8496588 [details] [diff] [review]
base-view-refresh.diff

Review of attachment 8496588 [details] [diff] [review]:
-----------------------------------------------------------------

r=philipp with these comments considered:

::: calendar/base/content/calendar-base-view.xml
@@ +258,5 @@
>          Services.prefs.addObserver("calendar.", this.mPrefObserver, false);
>          this.weekStartOffset = Preferences.get("calendar.week.start", 0);
>          this.updateDaysOffPrefs();
> +        this.mPendingRefreshJobs = new Map();
> +        this.mLog = Log4Moz.getConfiguredLogger("calBaseView");

Do you want to leave the log in? We can save the extra perf hit by removing it if you think this is only useful for developer debugging.

If you think you can get useful information out of a user that enables this pref, we can keep it.

@@ +474,5 @@
> +                  }
> +                  let items = aItems.filter(function(x) !cal.isToDo(x) ||
> +                                            (x.entryDate || x.dueDate));
> +
> +                  for (let item of items) {

Since you are going through a for loop anyway, I'd suggest just integrating the filter condition into the loop, otherwise the code has to go through it twice.

@@ +481,5 @@
> +              },
> +
> +              cancel: function() {
> +                  this.calView.mLog.info("Refresh cancelled for calendar " + this.calId);
> +                  if (this.operation && this.operation.isPending) {

I know we don't have many providers that actually use the operations. While this doesn't mean we should throw out the code, I'm wondering how multiple refresh calls are now handled. Naively I'd assume that nothing is canceled because there is no operation, and a further getItems call gets made when forceRefresh is called.

Maybe you should add a canceled flag in the refresh job that gets checked in onGetResult/onOperationComplete and then doesn't fire viewloaded. This is not ideal in terms of performance of course, but might save us from double events.

What do you think?

@@ +492,5 @@
> +                  if (!this.calView.startDate || !this.calView.endDate || !aCalendar) {
> +                      return;
> +                  }
> +
> +                  if (aCalendar.type == "composite") {

Do we ever refresh from something other than the composite calendar?
Attachment #8496588 - Flags: review?(philipp) → review+
Could you provide an updated patch for check-in?
Flags: needinfo?(matthew.mecca)
(In reply to Philipp Kewisch [:Fallen] from comment #42)
> Do you want to leave the log in? We can save the extra perf hit by removing
> it if you think this is only useful for developer debugging.
> 
> If you think you can get useful information out of a user that enables this
> pref, we can keep it.

I thought it might be useful if this type of issue pops up again.


> Since you are going through a for loop anyway, I'd suggest just integrating
> the filter condition into the loop, otherwise the code has to go through it
> twice.

done.

> Maybe you should add a canceled flag in the refresh job that gets checked in
> onGetResult/onOperationComplete and then doesn't fire viewloaded. This is
> not ideal in terms of performance of course, but might save us from double
> events.

done.

> Do we ever refresh from something other than the composite calendar?

We do when a calendar is shown, so we don't have to do an unnecessary refresh of the whole composite.
Status: NEW → ASSIGNED
Flags: needinfo?(matthew.mecca)
Attached patch Fix v2Splinter Review
Patch for check-in
Attachment #8496588 - Attachment is obsolete: true
Attachment #8519493 - Flags: review+
Keywords: checkin-needed
https://hg.mozilla.org/comm-central/rev/a01fb28145bc
Status: ASSIGNED → RESOLVED
Closed: 10 years ago7 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 3.8
You need to log in before you can comment on or make changes to this bug.