1760805 - Thunderbird UI unusable after timezone detection failed on systems that use short timezone names - missing mail folder tree and message list at startup

Status: VERIFIED FIXED

(Calendar :: General, defect, P1)

Description

Thunderbird daily fails to set calendar.timezone.local on Windows 11 x64 (at least with OS locale Japanese).

Thunderbird tries to set timezone "Etc/GMT-9" and then it is failed.
(The correct time zone is "Asia/Tokyo".)

This prevents the mail folder tree and message list from appearing at startup.

Regression window by mozregression:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=d2b02892f0b4cd95d470ca2020075767098c3fd4&tochange=6101012f0de3f15cf8018190c0e3a824519ce59b

Possibly regressed by bug 1158733.

Comment 1

[Takanori MATSUURA]

The mail folder tree and message list are shown by manually adding "Asia/Tokyo" to calendar.timezone.local.

Comment 2

[Wayne Mery (:wsmwk)]

Thanks for getting the regression range

Comment 3

[Martin Schröder [:mschroeder]]

I had a look at it. We should probably add the whole range of timezones prefixed "Etc/GMT" to the internal timezone database as they seem to be canonical timezones. I will try to find a mapping to the geographically named timezones and how it is supposed to work based on the IANA tz database.

Comment 4

[Takanori MATSUURA]

"Asia/Tokyo" is set for "Tokyo Standard Time" with country "JP" in the following files:
https://searchfox.org/mozilla-central/rev/80f11ac5d938f6fce255c56279f46f13a49ea5c3/intl/icu/source/data/misc/windowsZones.txt#647-654
https://searchfox.org/mozilla-central/rev/80f11ac5d938f6fce255c56279f46f13a49ea5c3/intl/tzdata/source/windowsZones.txt#647-654
(I don't know which file is referred in this situation)

I found that "tzutil /g" command returns "Tokyo Standard Time_dstoff" not "Tokyo Standard Time".
I don't know how Firefox detect the timezone information on Windows OS, but it's interesting.

Comment 6

[Lasana Murray]

Sean, are you able to look into this?

Comment 7

[Kai Engert [:KaiE:]]

Martin, would it make sense to fix this bug by adding a full list of short alias time zone names to zones.json?

Comment 8

[Kai Engert [:KaiE:]]

Side remark: the zones.json file contains multiple alias definitions that point to "UTC", but apparently it doesn't contain a definition for "UTC"

Comment 9

[Kai Engert [:KaiE:]]

I'm trying to push this a bit forward, because I think this is a serious issue and needs to block the stable 102 release.

Bug 1158733 removed a call to guessSystemTimezone(), and replaced it with a call to Intl.DateTimeFormat().resolvedOptions().timeZone

It seems this isn't providing equivalent functionality.

Would it be reasonable to add the fold code as a fallback?
Pseudo code:

tzid = Intl.DateTimeFormat().resolvedOptions().timeZone;
if (cannot find tzid in zones.json) {
tzid = guessSystemTimezone();
}

Would we still be able to do this on the 102 branch, given that the commit from bug 1158733 removed lots of strings that were required for the guessSystemTimezone() code? Would we be able to restore the old strings, given that we're after the string freeze?

Comment 10

[Kai Engert [:KaiE:]]

Attachment: This is an experimental patch, on top of the backout, to keep trying the new lookup Intl.DateTimeFormat().resolvedOptions().timeZone, but fall back to the old code if it doesn't work.

I played with this a bit.

I'm describing a way to keep the new code, but if it fails, fall back to the old back (which required that we'd have to backout the change).

What I did is:

• revert the patch from bug 1158733 (which still applies, at least to beta 102)
• apply a small patch on top to use the new code first

I'm attaching that patch, which fixes the issue for me.

I cannot say if this is the best approach, it's just an experiment, and a worst-case suggestion (if we cannot find a better approach).

Let's wait for Sean's assessment.

Comment 11

[Kai Engert [:KaiE:]]

Magnus, just for discussing our options: Please have a look at the patch from bug 1158733 - Would it be possible to backout that on 102 - and bring back the strings? Or is it too late?

Comment 12

[Magnus Melin [:mkmelin]]

The old strings are still available if we need them. https://searchfox.org/l10n/search?q=likelyTimezone&path=&case=false&regexp=false

Comment 13

[Sean Burke [:leftmostcat]]

This seems like a reasonable fix for the time being, though it feels like we'll want tickets both to implement a better fix (i.e., make sure that the new code properly handles all IANA timezones) and—naively, not sure what this would take—to have some sort of sane fallback for the UI in the worst case where we fail to get the timezone right.

Comment 14

[Kai Engert [:KaiE:]]

Attachment: Bug 1760805 - Backout and restore code from bug 1158733, we still need it in a fallback scenario. r=leftmostcat

Comment 15

[Kai Engert [:KaiE:]]

Attachment: Bug 1760805 - If the system timezone name cannot be found in our list, fall back to classic guessing. r=leftmostcat

Depends on D149250

Comment 16

[Kai Engert [:KaiE:]]

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

This seems like a reasonable fix for the time being, though it feels like we'll want tickets both to implement a better fix (i.e., make sure that the new code properly handles all IANA timezones) and—naively, not sure what this would take—to have some sort of sane fallback for the UI in the worst case where we fail to get the timezone right.

Sounds good, do you want to file those bugs?

Comment 17

[Martin Schröder [:mschroeder]]

(In reply to Kai Engert (:KaiE:) from comment #7)

Martin, would it make sense to fix this bug by adding a full list of short alias time zone names to zones.json?

This seems like the correct fix. In my opinion, not all (relevant) timezone names are generated from the tzdata and added to zones.json. Another option would be adding them statically to zones.json and not change the generation process. I also missed some error handling when I changed the code. The existence of the resolved timezone in the shipped timezones (zones.json) should always be checked. If the timezone is unknown, the user should decide what he wants to set as the timezone.

Comment 18

[Kai Engert [:KaiE:]]

It seems that is will be more work to get the fixes Martin describes in comment 17.

I suggest that we go ahead and land the fixes that I've attached. Sean had already agreed in general, but we need his r+ to land them.

Comment 20

[Kai Engert [:KaiE:]]

Comment on attachment 9281198 [details]
Bug 1760805 - Backout and restore code from bug 1158733, we still need it in a fallback scenario. r=leftmostcat

[Approval Request Comment]
Regression caused by (bug #): 1158733
User impact if declined: TB with fresh profiles completely broken on many systems that use short time zone codes
Testing completed (on c-c, etc.): only manually so far, but should be fine after landing on c-c
Risk to taking this patch (and alternatives if risky): should be low risk, we're restoring code that worked in previous production releases, and are tweaking it slightly

Comment 21

[Magnus Melin [:mkmelin]]

I see there was a "warningUsingFloatingTZNoMatch" case earlier. Didn't look closely, but

Comment 22

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/06c61f39cb3a
Backout and restore code from bug 1158733, we still need it in a fallback scenario. r=leftmostcat
https://hg.mozilla.org/comm-central/rev/5ace4ab3f00f
If the system timezone name cannot be found in our list, fall back to classic guessing. r=leftmostcat

Comment 23

[Wayne Mery (:wsmwk)]

Comment on attachment 9281198 [details]
Bug 1760805 - Backout and restore code from bug 1158733, we still need it in a fallback scenario. r=leftmostcat

[Triage Comment]
Approved for beta

Comment 24

[Wayne Mery (:wsmwk)]

Comment on attachment 9281199 [details]
Bug 1760805 - If the system timezone name cannot be found in our list, fall back to classic guessing. r=leftmostcat

[Triage Comment]
Approved for beta

Comment 25

[Rob Lemley [:rjl]]

Thunderbird 102.0beta7:
https://hg.mozilla.org/releases/comm-beta/rev/2ea9d232ff26
https://hg.mozilla.org/releases/comm-beta/rev/8349e31bf505

Comment 26

[Kai Engert [:KaiE:]]

Hello Takanori MATSUURA, is the bug fixed for you, too?

Comment 27

[Takanori MATSUURA]

It seems to be fixed.

Comment 28

[Kai Engert [:KaiE:]]

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

This seems like the correct fix. In my opinion, not all (relevant) timezone names are generated from the tzdata and added to zones.json. Another option would be adding them statically to zones.json and not change the generation process. I also missed some error handling when I changed the code. The existence of the resolved timezone in the shipped timezones (zones.json) should always be checked. If the timezone is unknown, the user should decide what he wants to set as the timezone.

Martin, could you please file a follow-up bug to get track this, and reference it here?

(I just had a look at https://github.com/mozilla-comm/ical.js - and ran grunt package-zones - and the resulting file gives me definitions for many short names, including "CET" and "Etc/GMT-9".)

Comment 29

[Kai Engert [:KaiE:]]

Rob, it would be great to check that localized versions of 102 indeed contain the localized strings from the backout. When you work on localized builds, could you please check one random language to verify?

Comment 30

[John Bieling (:TbSync)]

I was asked to test this on https://archive.mozilla.org/pub/thunderbird/candidates/102.0-candidates/build1/.

The default timezone on my system is Europe/Berlin, but it looks like I have to trigger this with a non default timezone? It was not possible through the UI. So I changed calendar.timezone.local to Etc/GMT-9 and restarted. Thunderbird did not properly start up, but showed the behaviour described in this bug.

Is that the correct way to trigger this bug?

Comment 31

[Kai Engert [:KaiE:]]

(In reply to John Bieling (:TbSync) from comment #30)

The default timezone on my system is Europe/Berlin, but it looks like I have to trigger this with a non default timezone? It was not possible through the UI. So I changed calendar.timezone.local to Etc/GMT-9 and restarted. Thunderbird did not properly start up, but showed the behaviour described in this bug.

Is that the correct way to trigger this bug?

No.

If your system timezone name is a supported value, then it probably isn't sufficient to change Thunderbird's own pref calendar.timezone.local to that value.

Comment 32

[Kai Engert [:KaiE:]]

Regarding my request to Rob from comment 29:
I found a localized german build at
https://archive.mozilla.org/pub/thunderbird/candidates/102.0-candidates/build1/linux-x86_64/de/

I confirmed that one of the restored strings indeed came back in the localized builds, too.
(I looked at WarningUsingGuessedTZ).

I tested it on a system with timezone value CET, and this bug is fixed for me.

Comment 33

[Kai Engert [:KaiE:]]

In addition I tested locale "be", which lacks translations for many strings. However, it does have the original english string. So for the purpose of fixing this bug, it seems guaranteed that we'll have the english fallback strings at the least.