Closed Bug 1022129 Opened 10 years ago Closed 10 years ago

In the calendar views the day marked as Today doesn't update at midnight

Categories

(Calendar :: Calendar Frontend, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED

People

(Reporter: bv1578, Assigned: bv1578)

Details

Attachments

(1 file, 3 obsolete files)

When the system clock changes day at midnight, Lightning updates the "Today" status of all the elements: today-pane, minimonths, today-pane button, ... but in the calendar views (any view) the day marked as "today" doesn't change.

This bug is caused by the new behaviour introduced with the patch for bug 872063.
Attached patch patch - v1 (obsolete) β€” β€” Splinter Review
This patch forces the refresh by calling the method goToDay() with a null parameter (already possible for multiweek and month view, now added to day and week view too).
Attachment #8436467 - Flags: review?(philipp)
Attachment #8436467 - Flags: review?(philipp) → review+
There is a similar problem. The "today" doesn't change upon resume from suspend.
(In reply to Chen Wei from comment #2)
> There is a similar problem. The "today" doesn't change upon resume from
> suspend.

I've just tested suspending and hibernating the PC before 00:00 and the patch seems fixing in both cases when resuming the machine but actually the problem is different because it seems I've completely forgot the idea behind the patch for bug 872063.
I'm working on a new patch.
Attached patch patch - v2 (obsolete) β€” β€” Splinter Review
All the views that have been already displayed before midnight need to be refreshed and not only that one currently displayed (the others get refreshed, and today updated, the first time they are displayed).


About the resume after suspend or hibernation, I've tested a bit and I've found different behaviours. Sometimes "today" gets updated, sometimes not (more difficulty upon the hibernation) but mostly it works, at least with brief suspensions.
When the update occurs, it happens not instantly when the system turns on the screen but a few seconds later (2,5,10 sometimes more) depending on system activity.
When the update doesn't occur, you can move the pointer over an element in the UI that reacts to mouse overview (e.g. a button) to get the update (even without clicking on Thunderbird's window). It sounds like it needs something to unblock scheduled operations related to timers.
It doesn't seem a problem related to this bug or the patch for bug 872063.
Attachment #8436467 - Attachment is obsolete: true
Attachment #8437287 - Flags: review?(philipp)
Comment on attachment 8437287 [details] [diff] [review]
patch - v2

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

r- to get this comment resolved, please re-request if we come to the conclusion that its ok:

::: calendar/lightning/content/messenger-overlay-sidebar.js
@@ +202,5 @@
> +            let cview = document.getElementById(view);
> +            if (cview.initialized) {
> +                cview.forceRefresh();
> +            }
> +        });

Am I right that this will increase the number of getItems calls by max 3? The goal is to use the cache for everything, but in uncached mode this makes things worse.

Is there a way we could postpone the refresh for the non-current views until the view is actually changed?
Attachment #8437287 - Flags: review?(philipp) → review-
For the suspend/hibernate problem, see also bug 682109 if you are experiencing it on linux.
Attached patch patch - v3 (obsolete) β€” β€” Splinter Review
(In reply to Philipp Kewisch [:Fallen] from comment #5)

> Am I right that this will increase the number of getItems calls by max 3?

Yes, you are right, it could be an heavy and useless load with big and many calendars.

This patch should work in the right way. It refreshes the current view and changes the condition that prevents the refresh for the optimization introduced with bug 872063 in the others views.
mToggleStatus is set again to the correct value in the first relayout.
Attachment #8437287 - Attachment is obsolete: true
Attachment #8440755 - Flags: review?(philipp)
Comment on attachment 8440755 [details] [diff] [review]
patch - v3

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

Looks good, r=philipp
Attachment #8440755 - Flags: review?(philipp) → review+
Attached patch patch - v3 for checkin β€” β€” Splinter Review
Patch v3 with data for checkin.

r=philipp
Attachment #8440755 - Attachment is obsolete: true
Attachment #8446404 - Flags: review+
https://hg.mozilla.org/comm-central/rev/5224c3a3621a
Status: ASSIGNED → RESOLVED
Closed: 10 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → 3.5
You need to log in before you can comment on or make changes to this bug.