1777741 - 102.0 MacOS X issues - main window is empty. Error window said about 'Uncaught TypeError: gFolderDisplay is null'

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, defect)

Description

[Anton Samets]

Attachment: main window

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:103.0) Gecko/20100101 Firefox/103.0

Steps to reproduce:

Hello. I've upgraded from 91.0.1 version to 102.0 and I miss everything and my main window is empty. Error window said about 'Uncaught TypeError: gFolderDisplay is null'
I've tried to run in safe mode without addons - didn't help. I've not tried to run in another profile, because I need my current.

Actual results:

Main window doesn't show any UI for working with email.
Error log is full with:
Uncaught TypeError: gFolderDisplay is null
updateCheckedStateForIgnoreAndWatchThreadCmds chrome://messenger/content/mailWindowOverlay.js:161
goUpdateMailMenuItems chrome://messenger/content/mailWindowOverlay.js:145
oncommandupdate chrome://messenger/content/messenger.xhtml:1
view_init chrome://messenger/content/mailWindowOverlay.js:415
onpopupshowing chrome://messenger/content/messenger.xhtml:1

and
Uncaught
Exception { name: "NS_ERROR_UNEXPECTED", message: "Component returned failure code: 0x8000ffff (NS_ERROR_UNEXPECTED) [nsIPrefBranch.getIntPref]", result: 2147549183, filename: "resource:///modules/UIFontSize.jsm", lineNumber: 96, columnNumber: 0, data: null, stack: "@resource:///modules/UIFontSize.jsm:96:34\n@chrome://messenger/content/tabmail.js:13:34\n", location: XPCWrappedNative_NoHelper }

Expected results:

All should work as it was.

Comment 1

[Anton Samets]

Attachment: error.log window

Comment 2

[Anton Samets]

Attachment: about window

Also in "about" it suggest to upgrade, but it doesn't work - after pressing to "Restart to upgrade Thunderbird" nothing changes - issue is the same.

Comment 3

[Wayne Mery (:wsmwk)]

gFolderDisplay is null is also reported at bug 1772974

Comment 4

[Anton Samets]

I've solved my problem with removing from prefs.js the strings which begins with "font.". I've backuped the existed file and make some diffs for "fresh" prefs.js and cheched, what exactly was in the source.
I have the next things:
user_pref("font.default.x-cyrillic", "serif");
user_pref("font.default.x-user-def", "serif");
user_pref("font.default.x-western", "serif");
user_pref("font.internaluseonly.changed", true);
user_pref("font.language.group", "x-user-def");
user_pref("font.name.monospace.x-cyrillic", "Courier New");
user_pref("font.name.monospace.x-user-def", "Courier New");
user_pref("font.name.monospace.x-western", "Courier New");
user_pref("font.name.sans-serif.x-cyrillic", "Segoe Print");
user_pref("font.name.sans-serif.x-user-def", "Ubuntu");
user_pref("font.name.sans-serif.x-western", "Ubuntu");
user_pref("font.name.serif.x-cyrillic", "Ubuntu");
user_pref("font.name.serif.x-user-def", "Ubuntu");
user_pref("font.name.serif.x-western", "Ubuntu");
user_pref("font.size.fixed.x-cyrillic", 14);
user_pref("font.size.fixed.x-user-def", 14);
user_pref("font.size.fixed.x-western", 14);
user_pref("font.size.variable.x-cyrillic", 14);
user_pref("font.size.variable.x-user-def", 14);
user_pref("font.size.variable.x-western", 14);

After removing all works like a charm, but it's better to add more checks for custom font settings for fresh versions.
Thank you.

Comment 5

[Magnus Melin [:mkmelin]]

It certainly looks possible we would access prefs that are not set.
https://searchfox.org/comm-central/rev/9d99b2706b19fa0f9153d922f8234b1107270789/mail/modules/UIFontSize.jsm#94-95 with langGroup being a localized pref.

We should add a default value second parameter to the getIntPref calls. But what values?

Comment 6

[Alessandro Castellani [:aleca]]

Uh, interesting issue.
I think we could do something like this:

If the langGroup pref is not defined for whatever reason, we can use x-user-def as that seems to be the default value not changed by a localized pref.
Regarding the VARIABLE_SIZE and the MONOSPACE_SIZE attributes, if any of those is not available, we can fallback to the this.size for both in order to keep the increase/decrease of messages consistent with the application UI.

Does this sound correct?
Are we potentially missing something?

Comment 7

[Magnus Melin [:mkmelin]]

I'm not sure what x-user-def is. Yes it seems using this.size for the others would make sense.

Looking further, I guess this is an expected problem: have the localized langGroup pref set to something invalid. Like https://searchfox.org/l10n/source/rw/toolkit/chrome/global/intl.properties#39 (which does seem like a bug), the pref wouldn't exist and things blow up.

Comment 8

[Magnus Melin [:mkmelin]]

Attachment: Bug 1777741 - Make sure fontsize contols do not break for invalid/missing pref. r=aleca

Comment 9

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/e5ee2e85e604
Make sure fontsize contols do not break for invalid/missing pref. r=aleca

Comment 10

[Magnus Melin [:mkmelin]]

Comment on attachment 9286997 [details]
Bug 1777741 - Make sure fontsize contols do not break for invalid/missing pref. r=aleca

[Approval Request Comment]
Regression caused by (bug #): new font size controls
User impact if declined: may get broken ui
Testing completed (on c-c, etc.): c-c
Risk to taking this patch (and alternatives if risky): safe

Comment 11

[Wayne Mery (:wsmwk)]

Comment on attachment 9286997 [details]
Bug 1777741 - Make sure fontsize contols do not break for invalid/missing pref. r=aleca

[Triage Comment]
Approved for beta

Comment 12

[Rob Lemley [:rjl]]

Thunderbird 104.0b2:
https://hg.mozilla.org/releases/comm-beta/rev/b261ed96ae8c

Comment 13

[Wayne Mery (:wsmwk)]

Comment on attachment 9286997 [details]
Bug 1777741 - Make sure fontsize contols do not break for invalid/missing pref. r=aleca

[Triage Comment]
Approved for esr102

Comment 14

[Rob Lemley [:rjl]]

Thunderbird 102.1.1:
https://hg.mozilla.org/releases/comm-esr102/rev/cca3faea80da