1690620 - Calendar time is progressively incorrect

Status: RESOLVED FIXED

(Calendar :: General, defect, P1)

Description

[Pete d'Oronzio]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:85.0) Gecko/20100101 Firefox/85.0

Steps to reproduce:

Open my calendar to today and sit back and watch. (i.e. do nothing, but don't switch to another tab like email or tasks, etc.)

Windows 10; Thunderbird 78.7; Calendar "Week" view; about 9 calendars enabled; All are Google sync'd.

Actual results:

Over the course of a day, the red bar indicating the current time of day loses time. (falls behind) It corrects itself upon leaving and activating the calendar tab. This has two problematic effects:

1. The red bar indicates it is 11am when in fact I just missed my 12:30 appointment.
2. Reminders pop-up late. It seems it's not just the display, but the internal clock in the calendar. So if I leave the calendar page and sit on the inbox page for 4 hours, I will rarely get a reminder. When I return to the calendar page, all the missed reminders suddenly pop up. Same thing happens when sitting on the calendar page but not doing anything that causes a refresh.

Expected results:

The time (as shown by the red horizontal bar in today's calendar) falls behind as much as 15/minutes per hour. This adds up quickly. It corrects itself upon refresh of the calendar tab.
Expected results - calendar clock should keep time.

Comment 1

[Pete d'Oronzio]

Attachment: 2021-02-12 06.32 PdMagic.mp4

This morning, rather than the clock having lost time, it has gained time. Almost 12 hours overnight.

Comment 2

[Martin Schröder [:mschroeder]]

This bug description sound partly like a duplicate of bug 1665374.

Comment 3

[Martin Schröder [:mschroeder]]

Pete, do you still experience this issue? Have you tried Thunderbird 91 yet?

Comment 4

[Pete d'Oronzio]

Hi Martin,
I had not upgraded yet. Doing so now. Will report as soon as I know if it still occurs.
Pete

Comment 5

[Eric L.]

As I already wrote in #1665374 I have an issue which definitely looks similar, but not exactly the same, but is still present in 91.1.0 (Fedora 34):

• I never noticed that the delay grows over the course of the day
• I've never seen it be too early
• I didn't realize that it had an influence on the alarms, but I also had a few cases where I came too late because I didn't see the alarm (I can't have sound in an open plan office). It didn't happen very often and I did put it on me not paying attention to the pop-up, but perhaps I have now a better excuse :-P

This said, it's really erratic and it happens since rather a long time, it just didn't get enough on my nerves that I'd create a ticket earlier. And I also have multiple Google calendars synced (5 of them), so it seems that, even if there are somewhat different symptoms, they belong to the same issue.

Comment 6

[Pete d'Oronzio]

(In reply to Martin Schröder [:mschroeder] from comment #3)

Pete, do you still experience this issue? Have you tried Thunderbird 91 yet?

I've now run v91 for the past week and have not experienced the error. I'll come back and post if I do, but I'm pretty sure I would have seen it by now.
Thanks!
Pete

Comment 7

[Markus]

Hello,
i am using Thunderbird v91 and still have the exact same issue.

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.1.2
OS: Linux 5.14.10-1-MANJARO #1 SMP PREEMPT Thu Oct 7 06:43:34 UTC 2021

Markus

Comment 8

[emorgan33]

Hello,
Here is a workaround: You can fix this by going to Thunderbird's Config Editor and changing the update interval from 15 to 1. The name of the config item to change is: calendar.view.timeIndicatorInterval

Cheers!

Comment 9

[cbf123]

My time bar was way more than 15min out of date (it was closer to an hour) but changing : calendar.view.timeIndicatorInterval to 1 caused it to update to the current time. We'll see if it stays that way.

Comment 10

[cbf123]

Setting calendar.view.timeIndicatorInterval to 5 minutes didn't work, it still lost sync with the current time. I'm testing 1min now.

Comment 11

[Pete d'Oronzio]

Hi again. I originally reported this bug 2 years ago. Since then I tried using another desktop client for while. I just came back to TB. I installed v102.9.1 (64-bit) on Windows 11 and today just experienced this old problem.
I haven't tried the calendar.view.timeIndicatorInterval because I the calendar time had lapsed by 4 hours, not minutes.
Has anyone found a solution to this? I understand a rewrite is in the works, so perhaps this will just have to wait for that.
Thanks for a great product in any case!
Pete

Comment 12

[Sean Burke [:leftmostcat]]

How frequently does this occur for you? If you can, when it occurs and before you force it to refresh, could you open up the developer tools (Tools > Developer Tools > Developer Toolbox), go to the Console tab, and type in timeIndicator.timer? It should either print a number or null.

Comment 13

[Pete d'Oronzio]

(In reply to Sean Burke [:leftmostcat] from comment #12)

How frequently does this occur for you? If you can, when it occurs and before you force it to refresh, could you open up the developer tools (Tools > Developer Tools > Developer Toolbox), go to the Console tab, and type in timeIndicator.timer? It should either print a number or null.

I think it is occurring regularly, but since moving focus from calendar to email back to calendar fixes it, it's hard to catch. I've just set up a calendar instance on it's own monitor alongside a dev tools window. That way when it occurs I should be able to enter timeIndicator.timer and get a result without refreshing the calendar page.

I'll keep you posted.

Pete

Comment 14

[Pete d'Oronzio]

Attachment: Debug log extract. Last few lines show timer null then assigned after window resize

Hi Sean,
So, it took a while to occur, but I got it.  The simple answer to your question is that timer is null when the time is incorrect.  

Here is the value of timeIndicator when the time is stuck in the past (stuck on 5pm yesterday while it is 8am today):
`Object { timer: null, start: start(interval, thisArg), cancel: cancel(), lastView: "week-view" }`
When I resize the Thunderbird window, it corrects the time and the value of timeIndicator changes to:
`Object { timer: 2770, start: start(interval, thisArg), cancel: cancel(), lastView: "week-view" }`

I've got screen shots of the debug log alongside the calendar with a stopped timer as well as alongside the correct timer.  However, there are a lot of calendar events that I'd prefer not to post to the public.  If these images might be helpful, I'd be happy to forward them directly to you.  I could try to redact stuff, but it would look quite messy.

`

`

Actually - I have an image of the 

Hope this helps!
Pete

Comment 15

[Pete d'Oronzio]

Hi Sean,
So, it took a while to occur, but I got it. The simple answer to your question is that timer is null when the time is incorrect.

Here is the value of timeIndicator when the time is stuck in the past (stuck on 5pm yesterday while it is 8am today):
Object { timer: null, start: start(interval, thisArg), cancel: cancel(), lastView: "week-view" }
When I resize the Thunderbird window, it corrects the time and the value of timeIndicator changes to:
Object { timer: 2770, start: start(interval, thisArg), cancel: cancel(), lastView: "week-view" }

I've got screen shots of the debug log alongside the calendar with a stopped timer as well as alongside the correct timer. However, there are a lot of calendar events that I'd prefer not to post to the public. If these images might be helpful, I'd be happy to forward them directly to you. I could try to redact stuff, but it would look quite messy.

Actually - I have an image of the debug log showing the unassigned and then the assigned timer after refresh. I'll add it to the bug attachments in a sec.

Hope this helps!
Pete

Comment 16

[Pete d'Oronzio]

Attachment: Before and after clock freezes

Comment 17

[Sean Burke [:leftmostcat]]

Attachment: Bug 1690620 - use metronome for updating time indicator. r=#thunderbird-reviewers

Comment 18

[Pete d'Oronzio]

I just reviewed the code changes shown. Thank you for taking this on!

Just wanted to note that as indicated in the original bug report, this affected reminders as well. I'm not sure if it still does, but the code changes seem to only be related to the UI. Does the same logic need updating in the reminder code?

Thanks,
Pete

Comment 19

[Sean Burke [:leftmostcat]]

Prior to this patch, the time indicator uses an entirely different and more error-prone method of attempting to schedule updates. The most likely issue with that was failing to schedule the next update for some reason, and the information you provided shows that that was happening in your case. (If .timer was null, that shows that something failed to set up the timer for the next update, and once that happened, it would never update again.) That issue is fairly easily resolved, and this patch does so.

Reminders before this patch and both reminders and the time indicator after this patch use a more robust timer system that's built into Gecko. If you continue to have issues with reminders or the time indicator after you're using an updated version of Thunderbird containing this fix, there's something deeper going on and we'll end up needing a separate bug to address it. Fingers crossed everything works for you after this, though.

Comment 20

[Pete d'Oronzio]

Excellent. Thanks again!

Comment 21

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/4947d9b40c98
use metronome for updating time indicator. r=mkmelin

Comment 22

[John Bieling (:TbSync)]

It seems related, I am getting a lot of

TypeError: can't access property "style", this.nowIndicator is undefined: updateTimeIndicatorPosition@chrome://calendar/content/calendar-multiday-view.js:2262:7

in tests (but not fail, just the error on the console)

For example here:
https://firefoxci.taskcluster-artifacts.net/YZxiQhYIS12TC9Pfd_E9Ww/0/public/logs/live_backing.log