1976182 - Day view: After each TAB change, the start time in the TAB calendar shifts

Status: RESOLVED FIXED

(Calendar :: General, defect)

Description

[edv-oldi]

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

Steps to reproduce:

My day starts at 8 a.m., after a change in other TAB, mail or tasks, the start time shifts by 2 hours.

Expected results:

Before the update to 140.0esr, the start time always remained at 8 o'clock.

Comment 1

[Corey Bryant]

_

Comment 2

[Magnus Melin [:mkmelin]]

Seems indeed to shift 2 hours back each time I go from calendar tab and task tab and back.
Alice, can you check what regressed this? Thanks in advance!

STR: open calendar in Day view. Switch between the Tasks tab and Calendar tab. Notice the view starts at a time further and further back.

Comment 3

[Alice0775 White]

Regression window:
https://hg-edge.mozilla.org/comm-central/pushloghtml?fromchange=55f5663c91fb13a75d59098a1414eb532440a443&tochange=8881e187ac9023ab23237ca153b169ca592e1fdd
https://hg-edge.mozilla.org/mozilla-central/pushloghtml?fromchange=7d5c498d3fc45ba32ad4aa54d99f69b210c34bf4&tochange=cf140d4031788a2daf896b9db13a8d0d73212ded

Comment 4

[Magnus Melin [:mkmelin]]

That as fast, thanks! This would be another regression from bug 1803713 then.
(This one should be pretty easy to add a test case for once fixed.)

Comment 5

[Magnus Melin [:mkmelin]]

It seems the first switch doesn't always cause it, but only switches after that.
The code appears to be in https://searchfox.org/comm-central/source/calendar/base/content/calendar-multiday-view.js but quite complicated

Comment 6

[Francesco]

Maybe fixed by bug 1976637.

Comment 10

[Francesco]

Please retest in Daily, likely fixed by bug 1976637.

Comment 12

[graham]

Really pleased to see that this bug has been [seemingly] fixed but seriously angry that it ever existed in the first place. Why did that happen? What part of the process resulted in bad code being released into the wild? What part of the code release process needs to be fixed? Any chance of someone involved being prepared to work on an approach that avoids this happening again in the future?

Comment 13

[Wayne Mery (:wsmwk)]

(In reply to graham from comment #12)

Really pleased to see that this bug has been [seemingly] fixed ....

This can be confirmed whether bug 1976637 fixes this by testing a THunderbird daily build.

A summary answer to your questions are found in previous comments and bug reports. It happened because of code inherited from bug 1803713 (i.e. not a change made by us), and lack of automated Thunderbird test as noted in comment 4. Further, bug 1956507 should have been elevated at the time it was filed and the regression range determined.

We are always looking for more testers, especially calendar users.

Comment 15

[Magnus Melin [:mkmelin]]

Just tested. Unfortunately NOT fixed. (And seems to change hours even more than I remember?)

Comment 16

[graham]

This can be confirmed whether bug 1976637 fixes this by testing a THunderbird daily build.

Sadly not. Downloaded and installed Daily - can't get past crash at start up. Ach!
It appears "seems" was an appropriate word to use. <sigh>

Comment 18

[Wayne Mery (:wsmwk)]

(In reply to graham from comment #16)

This can be confirmed whether bug 1976637 fixes this by testing a THunderbird daily build.

Sadly not. Downloaded and installed Daily - can't get past crash at start up. Ach!

What crash are you referring to? Do you have a crash ID?

Comment 19

[graham]

(In reply to Wayne Mery (:wsmwk) from comment #18)

(In reply to graham from comment #16)

This can be confirmed whether bug 1976637 fixes this by testing a THunderbird daily build.

Sadly not. Downloaded and installed Daily - can't get past crash at start up. Ach!

What crash are you referring to? Do you have a crash ID?

Just reproduced again. Crash ID: ⁨bp-adc9cdf0-0ebe-47d8-923e-8c09a0250909⁩. Attempt to restart... crashes again. When restoring to existing installation I get a message saying the profile has changed and may not be compatible. Fortunately I had a back-up.

Comment 20

[Magnus Melin [:mkmelin]]

Fixing the crash in bug 1987759.

Comment 21

[enzomas]

Attachment: Calendar tab in TB 143.0

With version 143.0, the whole calendar shifts upwards when switching to the tab, leaving an empty space.

Comment 22

[Harm van Bakel]

I noticed that this issue doesn’t have a priority or severity rating yet. Could someone perhaps confirm whether it’s actively being worked on? While it might be considered a minor (papercut) issue, it occurs very frequently throughout the day when switching between the calendar and mail view and has persisted in the ESR release for several months.

Comment 23

[Francesco]

It's not being worked on since the status is NEW and not ASSIGNED.

Comment 24

[Harm van Bakel]

I decided to give the monthly releases a try and it looks like the issue was fixed in version 143.

Comment 25

[Francesco]

The issue is still present in 144.0b4 and 145.0a1 (2025-10-11). Sometimes, switching back to the calendar tab is so bad that you get a blank screen as you scrolled to 30 o'clock, where there is nothing. So not fixed at all.

Comment 26

[graham]

Installed monthly 143.0.1 and tested this issue. Problem certainly different noting Comment 21.

Now if I switch from Calendar to Email then back to Calendar, it looks like to image attached to Comment 21 -- a view from ~19:00 to 30:00 with 24:00–30:00 being completely empty.

I f I then scroll the view to see earlier times, then switch back to Email, then back to Calendar it gets worse -- only the last 30 minutes of the day above a huge blank space.

The next bit is really weird. Switch back to Email then switch back to Calendar – it almost corrects but the view starts 2 hours later than my normal day-start-time.

Thereafter, it behaves differently.
Switch from Calendar to Email to Calendar = last 30 mins above empty space. Switch to Tasks to Calendar = view 2 hrs later than normal
Same for:
Switch from Calendar to Tasks to Calendar = last 30 mins above empty space. Switch to Email to Calendar = view 2 hrs later than normal
The above switch sequences can be repeated to produce the same effects over and over.

Ah but weirder still....
Scroll so as to correct the view to the normal day-start-time.
Now Switch from Calendar to Email/Tasks, then back to Calendar and the view is similar to that attached to Comment 21.
But then switch back to Emails/Tasks then back to Calendar, it corrects the view.

Mess.

Comment 28

[Toby Pilling [:tobyp]]

Is it just me or does switching to the Settings or Account Settings tab fix it each time, even if it was broken by switching to email/tasks?

Comment 29

[Francesco]

It's seems to be just you.

Add console.log(">> pos, minute", pos, minute); before this line:
https://searchfox.org/comm-central/rev/5424ac9176da227dc658269f7532c2a55cf3e628/calendar/base/content/calendar-multiday-view.js#3475

You will see that the calendar code requests the correct scroll by setting this.grid.scrollTop = pos. Sometimes Mozilla platform code scrolls to where was asked for, when switching back from some other tab, it doesn't. It looks like the Mozilla platform code is broken and you should ask there for help. Bug 1803713 changed the scroll behavior.

Comment 30

[Geoff Lankow (:darktrojan) [PTO, back 8 Dec]]

At that line, the code sometimes thinks the scrollTop is already (and wrongly) equal to pos, so setting the value to pos has no effect. If we set it to pos + 1 and then back again, the problem goes away (instead we have a horrible hack).

Comment 31

[Geoff Lankow (:darktrojan) [PTO, back 8 Dec]]

It's likely that bug 1976637 changed from the previous bad behaviour here to the current bad behaviour. Mozregression couldn't get the whole way down but the bug is in range. Hiro, could you have a look? See comment 30 for some info that might help.

Comment 32

[Hiroyuki Ikezoe (:hiro)]

Does the patch for bug 1978682 fix this bug?

Comment 33

[Geoff Lankow (:darktrojan) [PTO, back 8 Dec]]

Looks like it does, yes. Thank you!