Closed Bug 1665374 Opened 2 years ago Closed 1 year ago

Time of day indicator does not update automatically

Categories

(Calendar :: Calendar Frontend, defect)

Thunderbird 78
defect

Tracking

(thunderbird_esr78 wontfix, thunderbird87 affected, thunderbird88 affected, thunderbird89 fixed)

RESOLVED FIXED
90 Branch
Tracking Status
thunderbird_esr78 --- wontfix
thunderbird87 --- affected
thunderbird88 --- affected
thunderbird89 --- fixed

People

(Reporter: nneul, Assigned: darktrojan)

References

Details

(Keywords: regression, regressionwindow-wanted)

Attachments

(3 files)

Attached image tod.png

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/84.0.4147.89 Safari/537.36

Steps to reproduce:

View calendar in TB 78.2.2 . I did not see this with 68 previously.

Actual results:

The red horizontal line for time indicator doesn't update consistently. It seems to get displayed/set the first time you view the calendar and then doesn't move. I think it may only be updating if you switch completely out of the calendar view and then back into it, but I'm not sure it does that reliably.

At the very least, doing any operation that results in calendar redisplaying items should probably update that indicator. (i.e. changing displayed calendars, day/week view, etc.)

Expected results:

Time of day indicator should update automatically without user having to take any action.

Component: General → Calendar Views

This also impacts calendar notifications, they are not shown despite event is in the notification time range (15min). Only full thunderbird restart helps.

10min till end of the meeting and I get reminder (tb 78.4.3)

Attachment #9187681 - Flags: feedback+

Same experience here:

Thunderbird 78.3.2 (64-bit)
OS: Linux Pop!_OS 20.10

Toggling a calendar off and on again (using the little eye icon next to the calendar name in left panel) seems to kick the line along to the current time.

(In reply to Tim from comment #3)

Same experience here:

Thunderbird 78.3.2 (64-bit)
OS: Linux Pop!_OS 20.10

Toggling a calendar off and on again (using the little eye icon next to the calendar name in left panel) seems to kick the line along to the current time.

UPDATE: The red time indicator stays at the point where the calendar tab was redrawn and does not update automatically, even after toggling a calendar.

Duplicate of this bug: 1677237

Related tickets: 1637907 1671398

Duplicate of this bug: 1671398

I also have this issue:
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:78.0) Gecko/20100101 Thunderbird/78.6.1

Duplicate of this bug: 1688472
Status: UNCONFIRMED → NEW
Ever confirmed: true

I have this issue as well.
Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:87.0) Gecko/20100101 Thunderbird/87.0a1

I have this issue as well.
Using 78.7.0 (64-bit) on openSUSE Tumbleweed.

Switching to the following or preceding week in "Week View" and returning to the current week updates the position of the line for me.

Keywords: regression
Summary: Time of day indicator doesn't update automatically → Time of day indicator does not update automatically

beta channel is affected too. running 86.0b3 and the indicator line is stuck at the time thunderbird started regardless of settings in calendar.view.timeIndic....

Duplicate of this bug: 1690287

So this line is supposed to update/move every minute and show the user what the time is with a tool tip?
Mine increments every 15 minutes when I observe in my tests and compare it to my system time.

I guess if this is a regression, we want a regression window.

OS: Unspecified → All
Hardware: Unspecified → Desktop

It's been broken since something after 68, but I don't have a better timeframe for you.

I don't know about tooltip, but at the very least, if you switch off of the calendar view and come back, you shouldn't see a completely incorrect time line indicator.

In several cases, I've had the line be from when I looked at it the day before, resulting in an "oh (*&^@#$ I missed that meeting" reaction before brain catches up and realizes it can't trust what TB is showing.

Responding to #12 above, I don't believe it's from the time TB is started, but the time the calendar view is first shown.

It seems like it is possible to get it to correct by switching from Day->Week->Day or similar changes of view, but definitely does not update switching from calendar->mail->calendar or similar.

Same here. It's 5PM and the calendar shows 3PM.. For version 88 Beta 2 64 bit...

No, switching from Day->Week->Day or similar changes of view does not correct the pointer.

I just opened Build ID: 20210402105804 of Thunderbird 89.0a1 on Windows 10.
Checked the Day and week views and see the line at 11:00AM when it should be a quarter of the way down since it was 11:23AM at that time.
Closed and restarted and the line is now halfway down, representing 11:30AM.
Updated to Build ID: 20210403105520, restarted and the line is back at 11:00AM in Day and Week views.
Switched to Multiweek and back to Day view and the line is in the proper position. Week view is also correct.

I use Multiweek view.

Duplicate of this bug: 1702275
OS: All → Unspecified
Hardware: Desktop → Unspecified

I've found a cause of this problem, where the timer for updating the indicator is cancelled when switching calendar views but never restarted. However it can't be the only cause of the problem, because it's part of a bug 1684581 that landed in Thunderbird 86 (and somewhat fortuitously didn't get uplifted to Thunderbird 78 due to a mistake). I'll fix that and see what happens.

In bug 1684581 I changed this function to return early, but that was a mistake because the lower part of the function needs to run.

Assignee: nobody → geoff
Status: NEW → ASSIGNED

For anybody looking to further debug this, you can open the Error Console and type timeIndicator.timer to see if updating is active. The value will be a number if an update is scheduled (the number's value is meaningless), or null if not.

On Week View version 89 b1 is still there. Shows 10 AM and it is 10:57 AM now.

(In reply to Geoff Lankow (:darktrojan) from comment #22)

For anybody looking to further debug this, you can open the Error Console and type timeIndicator.timer to see if updating is active. The value will be a number if an update is scheduled (the number's value is meaningless), or null if not.

Using 89.0b1 on Fedora 33 Workstation I have

11:04:34.538 timeIndicator.timer
11:04:34.589 null

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/78f49df71073
Restart time indicator updates when switching calendar views. r=mkmelin

Status: ASSIGNED → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED

Marking this as fixed in 90 for now. As I said in comment 20 I don't think this is an adequate fix for 78 but I'm not sure how I'm going to deal with that. If somebody could provide some steps to reproduce in 78 that would be helpful (see comment 22).

Target Milestone: --- → 90 Branch

Comment on attachment 9217603 [details]
Bug 1665374 - Restart time indicator updates when switching calendar views. r?mkmelin

[Approval Request Comment]
Regression caused by (bug #): Bug 1684581
User impact if declined: Time indicator stops moving, which could mislead the user.
Testing completed (on c-c, etc.): Landed two weeks ago, no complaints (that I've seen) so far.
Risk to taking this patch (and alternatives if risky): Little to none.

Attachment #9217603 - Flags: approval-comm-beta?

Comment on attachment 9217603 [details]
Bug 1665374 - Restart time indicator updates when switching calendar views. r?mkmelin

[Triage Comment]
Approved for beta

Attachment #9217603 - Flags: approval-comm-beta? → approval-comm-beta+

Why can't this time pointer be fixed properly? It worked before so it's not like something brand new. Switching views is not the answer.

(In reply to nk2u@comcast.net from comment #30)

Why can't this time pointer be fixed properly? It worked before so it's not like something brand new.

Things break because of a specific set of actions (by the program or the user) that lead to something going wrong. We don't know what those actions are in this case.

Switching views is not the answer.

But switching views was a problem. Which we have now fixed.

I'm unsure:

  1. between the title and comments if it's the same issue,
  2. if I should recreate a new issue or ask to re-open this one,

Let me know how you want to handle this properly: under Thunderbird 91, the "current time" line doesn't update or only randomly/delayed (I can't recognize a pattern), indeed if I switch between views (e.g. week and day), then it updates and shows the correct time. But if I restart Thunderbird, the line sticks again at an outdated time.

$ rpm -qa | grep thunderbird
thunderbird-librnp-rnp-91.1.0-1.fc34.x86_64
thunderbird-91.1.0-1.fc34.x86_64

Eric, we still have bug 1690620 on file for similar behavior. Does this other bug report describe your issue?

Flags: needinfo?(ewl+mozilla)

I definitely looks similar, but not exactly the same:

  • 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).

Short, I'm now following bug 1690620 and we can track my problem over there if you prefer.

Flags: needinfo?(ewl+mozilla)
You need to log in before you can comment on or make changes to this bug.