Bug: General->Font Size is totally ignored and non-functional
Status: RESOLVED
Priority: --
Resolution: INVALID
Created: 2023-09-30 14:35:13+00:00
Resolved: 2023-10-01 15:01:18+00:00

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

Steps to reproduce:

Bug 1)
General->Font Size is totally ignored and completely non-functional.

I use Verdana font and setting all the Font Size to 15 is the same as setting to any other number like 9 or 10 or 12 ... I validated this bug many times, restarting Thunderbird after each change.

BTW I use Font Size 15 or sometimes 12 in Firefox, and General->Font Size works perfectly in Firefox which supposedly your UI is trying to emulate according to the lead architect's article on the web (but then why not use the same working UI framework they do?).

Bug 2)
When I am on the main window and Zoom to change the size of fonts in the email I am reading in the lower pane and then because of other bugs that pane cannot be expanded, I double click to get a full window to view the email, the font size setting that I just changed does not persist! This is obnoxious behavior because of Bug 1 where I cannot change the size permanently at all. The Zoom setting for email reading should persist when the email is popped out to a separate window. That would be an adequate workaround for not fixing Bug 1.

Bug 3)
Tools->Address Book->view one card has the "edit" button off the right side of the page and _none_ of the Edit name is visible! and there is no scroll bar. I didn't think I would see stuff like this in a modern app.
The only workaround is to Zoom-- and then the Edit button appears fully.

Bug 4)
Cannot resize lower pane showing actual message text to reduce the number of emails shown in the upper pane to minimal -- should be resizable to show *no* emails in the upper pane (like the old UI) which now forcibly takes up literally 1/2 of my screen!

Bug 5)
I forgot what this was as there as so many UI issues.

Bug 6)
This is not a new bug, but it would be fantastic if there was a way to hide the header (Subject, From, To) of emails (especially when on the main page, but even when the email is in its own window). Because that takes up a ton of space and on the main page I literally only see 2 lines of email text! Whereas if I could minimize the header (duh, I already see the Subject, From, To from the list of emails just above where one is highlighted so why do I need to see it below too if I don't want to waste that precious space), then I could see maybe 10 lines of text which might be sufficient to get a gist of the content.

Bug 7)
There is no Help button anywhere up top in any menus I can find. That is unacceptable. All you have to do is have a button point to a web page for help and to actual doc (god forbid you had an actual user manual!) such as this super useful but very very hidden page: https://kb.mozillazine.org/Category:Mail_(Thunderbird). A modern app with no Help accessible from the app. Do you care at all about users time in tracking down stuff like the above url?

Theory 1)
BEST THEORY TO EXPLAIN MANY OF THE ABOVE BUGS (besides your companies clear incompetence at UI design and implementation and total lack of testing using slightly bigger than usual fonts):
Because of my poor eyesight that requires a bit bigger fonts, I am forced to set layout.css.devPixelsPerPx=1.30 (see https://support.mozilla.org/gu-IN/questions/1345414 for details on how to do this) which Mozilla documents as the only way to increase the non-email-text font size. I have this also set in Firefox and it works fine.

=> Set that and *all* of these bugs are trivial to reproduce.
Maybe that's why you don't have as part of Settings any way to increase the size of all the fonts except in the read and compose email panes/windows.

Bug 8)
You don't provide the feature of increasing the font size of all the text outside of the read/write email panes. Instead of that you force folks to waste time to eventually discover setting layout.css.devPixelsPerPx to workaround this USABILITY BUG (if you can't read the font size, you can't use the app).

Bug 9)
This is not a new bug. *Regardless* of whether I sort the list of emails up or down, when I type b(ack) or f(orward) for email, it should go to the previous in *time* and the next in *time*. Otherwise it is very unintuitive. It's insane that go Back can mean the next email in time! I prefer to see the latest emails at the top of the page and Back goes forward in time.

Wishlist 1)
*All* panes should be resizable to the point where they are hidden. That would solve so many other UI mis-display issues (or at least workaround them).

Wishlist 2)
I wish your QA team would learn how to test when layout.css.devPixelsPerPx=1.30 or similar reasonable value (affects size of all non-email text) and when the General->Fonts sizes are changed (affects only email text *if* it was working at all as it did in the old UI).
I suspect the problem is that your engineers are not over 45 years old and need reading glasses, and *none* of them need bigger fonts to read text.
You clearly haven't done *any* testing of that aspect at all!
And yet that is the only way to increase the size of app menus/text that is not inside an email.


There's a hell of lot more wrong with the UI, but it all boils down to it not working well when font sizes are changed through either of the two known mechanisms, and the UI architect not understanding that some folks want to read their email on the main page without popping it out into its own window.
On the main page space is precious and email cannot be effectively read at all on that main page when devPixelsPerPx=1.30 and due to the non-resizeable nature of all panes (especially the list of emails pane).


Commentary:
BTW, all these super obvious display bugs were noticed in the first few *minutes* of using 115.3 (same for 115.3.1 released yesterday which didn't fix any of these issues). You should not have released this to the general public without an *easy* way to go back to the previous release which had *none* of these UI bugs (your framework is severely broken and I don't expect it to be fixed for years until you throw away that crappy UI framework that reminds me of the early 2000's where a larger than normal font size broke most apps).



**Actual results: (repeat of the above)**

Bug 1)
General->Font Size is totally ignored and completely non-functional.

I use Verdana font and setting all the Font Size to 15 is the same as setting to any other number like 9 or 10 or 12 ... I validated this bug many times, restarting Thunderbird after each change.

BTW I use Font Size 15 or sometimes 12 in Firefox, and General->Font Size works perfectly in Firefox which supposedly your UI is trying to emulate according to the lead architect's article on the web (but then why not use the same working UI framework they do?).

Bug 2)
When I am on the main window and Zoom to change the size of fonts in the email I am reading in the lower pane and then because of other bugs that pane cannot be expanded, I double click to get a full window to view the email, the font size setting that I just changed does not persist! This is obnoxious behavior because of Bug 1 where I cannot change the size permanently at all. The Zoom setting for email reading should persist when the email is popped out to a separate window. That would be an adequate workaround for not fixing Bug 1.

Bug 3)
Tools->Address Book->view one card has the "edit" button off the right side of the page and _none_ of the Edit name is visible! and there is no scroll bar. I didn't think I would see stuff like this in a modern app.
The only workaround is to Zoom-- and then the Edit button appears fully.

Bug 4)
Cannot resize lower pane showing actual message text to reduce the number of emails shown in the upper pane to minimal -- should be resizable to show *no* emails in the upper pane (like the old UI) which now forcibly takes up literally 1/2 of my screen!

Bug 5)
I forgot what this was as there as so many UI issues.

Bug 6)
This is not a new bug, but it would be fantastic if there was a way to hide the header (Subject, From, To) of emails (especially when on the main page, but even when the email is in its own window). Because that takes up a ton of space and on the main page I literally only see 2 lines of email text! Whereas if I could minimize the header (duh, I already see the Subject, From, To from the list of emails just above where one is highlighted so why do I need to see it below too if I don't want to waste that precious space), then I could see maybe 10 lines of text which might be sufficient to get a gist of the content.

Bug 7)
There is no Help button anywhere up top in any menus I can find. That is unacceptable. All you have to do is have a button point to a web page for help and to actual doc (god forbid you had an actual user manual!) such as this super useful but very very hidden page: https://kb.mozillazine.org/Category:Mail_(Thunderbird). A modern app with no Help accessible from the app. Do you care at all about users time in tracking down stuff like the above url?

Theory 1)
BEST THEORY TO EXPLAIN MANY OF THE ABOVE BUGS (besides your companies clear incompetence at UI design and implementation and total lack of testing using slightly bigger than usual fonts):
Because of my poor eyesight that requires a bit bigger fonts, I am forced to set layout.css.devPixelsPerPx=1.30 (see https://support.mozilla.org/gu-IN/questions/1345414 for details on how to do this) which Mozilla documents as the only way to increase the non-email-text font size. I have this also set in Firefox and it works fine.

=> Set that and *all* of these bugs are trivial to reproduce.
Maybe that's why you don't have as part of Settings any way to increase the size of all the fonts except in the read and compose email panes/windows.

Bug 8)
You don't provide the feature of increasing the font size of all the text outside of the read/write email panes. Instead of that you force folks to waste time to eventually discover setting layout.css.devPixelsPerPx to workaround this USABILITY BUG (if you can't read the font size, you can't use the app).

Bug 9)
This is not a new bug. *Regardless* of whether I sort the list of emails up or down, when I type b(ack) or f(orward) for email, it should go to the previous in *time* and the next in *time*. Otherwise it is very unintuitive. It's insane that go Back can mean the next email in time! I prefer to see the latest emails at the top of the page and Back goes forward in time.

Wishlist 1)
*All* panes should be resizable to the point where they are hidden. That would solve so many other UI mis-display issues (or at least workaround them).

Wishlist 2)
I wish your QA team would learn how to test when layout.css.devPixelsPerPx=1.30 or similar reasonable value (affects size of all non-email text) and when the General->Fonts sizes are changed (affects only email text *if* it was working at all as it did in the old UI).
I suspect the problem is that your engineers are not over 45 years old and need reading glasses, and *none* of them need bigger fonts to read text.
You clearly haven't done *any* testing of that aspect at all!
And yet that is the only way to increase the size of app menus/text that is not inside an email.


There's a hell of lot more wrong with the UI, but it all boils down to it not working well when font sizes are changed through either of the two known mechanisms, and the UI architect not understanding that some folks want to read their email on the main page without popping it out into its own window.
On the main page space is precious and email cannot be effectively read at all on that main page when devPixelsPerPx=1.30 and due to the non-resizeable nature of all panes (especially the list of emails pane).


Commentary:
BTW, all these super obvious display bugs were noticed in the first few *minutes* of using 115.3 (same for 115.3.1 released yesterday which didn't fix any of these issues). You should not have released this to the general public without an *easy* way to go back to the previous release which had *none* of these UI bugs (your framework is severely broken and I don't expect it to be fixed for years until you throw away that crappy UI framework that reminds me of the early 2000's where a larger than normal font size broke most apps).



**Expected results: (repeat of the above)**

Bug 1)
General->Font Size is totally ignored and completely non-functional.

I use Verdana font and setting all the Font Size to 15 is the same as setting to any other number like 9 or 10 or 12 ... I validated this bug many times, restarting Thunderbird after each change.

BTW I use Font Size 15 or sometimes 12 in Firefox, and General->Font Size works perfectly in Firefox which supposedly your UI is trying to emulate according to the lead architect's article on the web (but then why not use the same working UI framework they do?).

Bug 2)
When I am on the main window and Zoom to change the size of fonts in the email I am reading in the lower pane and then because of other bugs that pane cannot be expanded, I double click to get a full window to view the email, the font size setting that I just changed does not persist! This is obnoxious behavior because of Bug 1 where I cannot change the size permanently at all. The Zoom setting for email reading should persist when the email is popped out to a separate window. That would be an adequate workaround for not fixing Bug 1.

Bug 3)
Tools->Address Book->view one card has the "edit" button off the right side of the page and _none_ of the Edit name is visible! and there is no scroll bar. I didn't think I would see stuff like this in a modern app.
The only workaround is to Zoom-- and then the Edit button appears fully.

Bug 4)
Cannot resize lower pane showing actual message text to reduce the number of emails shown in the upper pane to minimal -- should be resizable to show *no* emails in the upper pane (like the old UI) which now forcibly takes up literally 1/2 of my screen!

Bug 5)
I forgot what this was as there as so many UI issues.

Bug 6)
This is not a new bug, but it would be fantastic if there was a way to hide the header (Subject, From, To) of emails (especially when on the main page, but even when the email is in its own window). Because that takes up a ton of space and on the main page I literally only see 2 lines of email text! Whereas if I could minimize the header (duh, I already see the Subject, From, To from the list of emails just above where one is highlighted so why do I need to see it below too if I don't want to waste that precious space), then I could see maybe 10 lines of text which might be sufficient to get a gist of the content.

Bug 7)
There is no Help button anywhere up top in any menus I can find. That is unacceptable. All you have to do is have a button point to a web page for help and to actual doc (god forbid you had an actual user manual!) such as this super useful but very very hidden page: https://kb.mozillazine.org/Category:Mail_(Thunderbird). A modern app with no Help accessible from the app. Do you care at all about users time in tracking down stuff like the above url?

Theory 1)
BEST THEORY TO EXPLAIN MANY OF THE ABOVE BUGS (besides your companies clear incompetence at UI design and implementation and total lack of testing using slightly bigger than usual fonts):
Because of my poor eyesight that requires a bit bigger fonts, I am forced to set layout.css.devPixelsPerPx=1.30 (see https://support.mozilla.org/gu-IN/questions/1345414 for details on how to do this) which Mozilla documents as the only way to increase the non-email-text font size. I have this also set in Firefox and it works fine.

=> Set that and *all* of these bugs are trivial to reproduce.
Maybe that's why you don't have as part of Settings any way to increase the size of all the fonts except in the read and compose email panes/windows.

Bug 8)
You don't provide the feature of increasing the font size of all the text outside of the read/write email panes. Instead of that you force folks to waste time to eventually discover setting layout.css.devPixelsPerPx to workaround this USABILITY BUG (if you can't read the font size, you can't use the app).

Bug 9)
This is not a new bug. *Regardless* of whether I sort the list of emails up or down, when I type b(ack) or f(orward) for email, it should go to the previous in *time* and the next in *time*. Otherwise it is very unintuitive. It's insane that go Back can mean the next email in time! I prefer to see the latest emails at the top of the page and Back goes forward in time.

Wishlist 1)
*All* panes should be resizable to the point where they are hidden. That would solve so many other UI mis-display issues (or at least workaround them).

Wishlist 2)
I wish your QA team would learn how to test when layout.css.devPixelsPerPx=1.30 or similar reasonable value (affects size of all non-email text) and when the General->Fonts sizes are changed (affects only email text *if* it was working at all as it did in the old UI).
I suspect the problem is that your engineers are not over 45 years old and need reading glasses, and *none* of them need bigger fonts to read text.
You clearly haven't done *any* testing of that aspect at all!
And yet that is the only way to increase the size of app menus/text that is not inside an email.


There's a hell of lot more wrong with the UI, but it all boils down to it not working well when font sizes are changed through either of the two known mechanisms, and the UI architect not understanding that some folks want to read their email on the main page without popping it out into its own window.
On the main page space is precious and email cannot be effectively read at all on that main page when devPixelsPerPx=1.30 and due to the non-resizeable nature of all panes (especially the list of emails pane).


Commentary:
BTW, all these super obvious display bugs were noticed in the first few *minutes* of using 115.3 (same for 115.3.1 released yesterday which didn't fix any of these issues). You should not have released this to the general public without an *easy* way to go back to the previous release which had *none* of these UI bugs (your framework is severely broken and I don't expect it to be fixed for years until you throw away that crappy UI framework that reminds me of the early 2000's where a larger than normal font size broke most apps).