Closed Bug 570442 Opened 14 years ago Closed 2 years ago

Need larger display font size for Thunderbird message list/pane and folder list/pane

Categories

(Thunderbird :: Mail Window Front End, defect)

defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 1715364

People

(Reporter: hyperrog, Assigned: aleca)

References

(Blocks 1 open bug)

Details

(Keywords: access)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_8; en-us) AppleWebKit/531.22.7 (KHTML, like Gecko) Version/4.0.5 Safari/531.22.7
Build Identifier: 3.0.4

See bug #471231 for FireFox which describes the issue perfectly.  For both older users, visually impaired users, and displays with high resolution, the main window font for the message list is just too small. Even old fashioned Eudora let you set the font size for the message list.

Reproducible: Always

Steps to Reproduce:
1. Open Thunderbird with screen resolution of 1440 x 900 on MacBook Pro.
2. Find someone over 50 to read it, or just try to read through the last month's email to find something.
3.
Actual Results:  
It's very difficult to read on higher resolution screens for this over-50 person.

Expected Results:  
There is a "display" preference, which should have a font size control for the message list and mailboxes, etc. in the main display.
layout.css.devPixelsPerPx=1.1 can be used for your purpose. It's known as simple workaround of problem around system DPI value setting on MS Win. 
See bug 549919 and bug 426788 for the problems.
The prefs is similar to value internally used in tab zooming of Fx. If the prefs is changed, it's applied to all dots including UI part such as menu.
Because the prefs is defined as "integer" in Tb 3.0, it's imposible to set 1.1 or 1.05 with Tb 3.0.x. However, the prefs is already defined as "string" in Tb 3.1 or later as Fx 3.6 already done, value like 1.05 or 1.1 can be specified on Tb.

AFAIK, Mac already abandoned "always 72DPI at physical display" and Mac also lies on "physical DPI value of physical display" as MS Win does since initial(AFAIK, chosen value by Apple is fortunately same as or near to Win's 96DPI). I think similar workaround on MS Win is possible on Mac.
> Expected Results:  
> There is a "display" preference, which should have a font size control for
> the message list and mailboxes, etc. in the main display.

As Fx/Tb uses Px in font size setting, easy to use magnifier is better to be provided by application. But, I believe responsible person of too small glyph size/too small image size problem due to mismatch between "higher than before  physical DPI of physical display" and "unchanged internal system DPI value" is mainly OS.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: access
Marco shall this bug block 396347 ?
OS: Mac OS X → All
Summary: Need larger display font for Thunderbird → Need larger display font for Thunderbird message list/ane and folder list/pane
Sorry I posted another duplicate, for some reason this one didnt come up when searching.  BUT ... the number of duplicates would suggest how much this feature is wanted. 

Wada's suggestion is not applicable for several reasons
1: Most people can't figure out config editor - hiding an important setting in a "warranty voiding" section of a product is a non-starter for 99% of TB users. 
2: Its really dangerous to set that one, I set it to +2 which seemed obvious to me (I presumed it meant 2 points bigger, this screwed up config editor so bad i had to hack prefs.js to get it back - 99.99% of TB users wouldnt have figured that out.
3: Even knowing the setting existed I didnt guess it could be fractional, again noone will figure that out. 

The setting actually does a reasonable job of improving the interface, I've adjusted mine so now - as a TB expert - I'm fine, but please lets get a UI fix into Preferences/Display for the 99% of TB users who dont read this, shouldn't touch Config Editor editor and of whom a sizable fraction can't read TB's display.
A problem in layout.css.devPixelsPerPx=1.2 like solution : icon is usually larger than we want when text size is good for us.
A simplest/popular solution in such case, which was used by many browser users for long time : 
    "Theme & Font Size Changer" Addon
The layout.css.devPixelsPerPx=1.2 solution has many many UI bugs, (apart from the high risk of completely bricking TB) there are far too many UI bugs to list here, it seems UI elements randomly pay attention to it or not, so sub-menus appear in the middle of the screen and so on. The most important requirment is being able to turn it on or off. 

Theme & Font Size Changer only works for a change of a couple of points, any bigger than that and the text overflows the boxes it is in.  Its main advantage is that you can turn it on or off (as you switch between working with and without glasses), while layout.css.devPixelsPerPx requires running config editor - with the risk of bricking TB.
I've added bug #1017625 for the worst case where once devPixels is set (correctly) the Preferences editor is made unusable so you cant change it back (or change any other preferences).
(In reply to Mitra Ardron from comment #12)
> I've added bug #1017625 for the worst case where once devPixels is set (correctly)
> the Preferences editor is made unusable so you cant change it back (or change any other preferences). 

It looks that "Panel Hight" attribute etc. is not relative to other attribute such as font-size, line-hight, window size etc. And, scrollbar/window-resize-small-box-at-corner like element is never defined for element which represent a panel or box in UI.
It's never fault in feature such as layout.css.devPixelsPerPx.
It's merely fault in UI design and implementatin especially in CSS setting.
see also bug 541379
See Also: → 541379
Summary: Need larger display font for Thunderbird message list/ane and folder list/pane → Need larger display font for Thunderbird message list/pane and folder list/pane
One can accomplish this via Chromedit with the following code:

tree > treechildren {
  font-size: value-larger-than-default !important;
}

That being said, I think we should investigate adding a way to increase font size.

We have a couple options:

1. Allow *all* font to be increased. (Pros: Universally better accessibility. Cons: May totally trash the UI)

2. Allow certain, more important elements to have increased font size (For example my line of CSS code above). (Pros: Better accessibility for the important information, not as damaging to the UI. Cons: Part of the UI will still be hard to read, inconsistency in font size.)

3. Keep this as an add-on.

I'm leaning towards #2 myself, which will also be a lot easier to implement.
Blocks: 1019652
Theme Font and Size Changer stopped working in Thunderbird 52.5. The Chromeedit workaround is still kinda-sorta working. However, a Chromedit size which fits in the message list, and the narrow rows there, is still uncomfortably small for reaing messages. An integrated setting might work better than add-ons and crude hacks for when the add-ons fail.
(In reply to MarjaE from comment #17)
> Theme Font and Size Changer stopped working in Thunderbird 52.5. 

Yeah, someone reported the same thing in bug 1428440. Highly doubtful it was caused by anything changed in Thunderbird - rather, that addon just seems to stop working on a regular basis because of some policy the author has in place.
This seems like something that shouldn't need an (unsupported) add-on to address. A pretty reasonable solution was proposed in Comment 16 four years ago. Is it still a reasonable solution?

As-is, the user interface is less than usable for nearly everyone who doesn't have eyes like a hawk. The population of email users is steadily aging, and that makes readability an increasingly important attribute. This issue probably should be considered higher priority than it has been treated to this point.
Totally agree, as someone making that transition to needing glasses, TB is one of the few things that I cannot use without them, almost everything else (especially anything browser based) allows a key combination or gesture to expand the text.  TB only allows it within the message pain, but not with the critical list of subjects. 

The extension was entirely useless, I had to disable it - I'd go back and check why, but its incompatible with current TB anyway.

<RANT>but unfortunately that is the norm for TB extensions (with notable exceptions  - they rarely work properly, and fail as TB is revised (5 out of 7 of my extensions are currently disabled as incompatible), but are used as an reason for not doing anything about the actual issue. </RANT>
I am the owner of one duplicate. I really hope to see this implemented. Judging by the number of duplicate tickets this is a really needed feature, right now the only solution is changing layout.css.devPixelsPerPx which is something the average user doesn't know how to do, or to use an add-on (with 15,000 users) that breaks regularly every 90 days..
@Wayne - that extension doesnt just stop working - as in incompatible, it generally doesn't work anyway, its always been an essentially unusable extension, mucking up the display badly enough to make it an absolute last resort. 

It beats me that noone has been able to fix this for 8 years, given that EVERY other application I use on the Mac has had a way to zoom in and out for ever. 

- Mitra
We're now at 6k people using the last resort of the last resort ;)
Wayne might have actually sped up the approval of the TB58+ fixed version. I never intended to actually debug or even develop this ****, but given that my blog visitor count casually DOUBLED after August 6th, the release day of TB60, there's clear demand of this functionality. I guess I could hard code that into some stylesheet for myself, but there are people that are unable to install a XPI file locally or even rename a ZIP file to XPI. This needs to be core functionality of Thunderbird, not a fragile addon.
See Also: → 1608288
Assignee: nobody → alessandro

I think this bug highlights an important issue of Thunderbird in terms of accessibility, which is the fact that font-sizes are hard coded via CSS and it's not possible to zoom in/out the whole interface at once.
The entire UI should be fluid, allowing users to increase/decrease font-size, alongside icons, and all the other scalable elements.

Let's discuss a plan of action and implement this into core in a sane and maintainable way.
I think this could be done in various steps.

  • Implement a global pref to allow users controlling the global font-size. This could be achieved by adding a font-size attribute to the window style, and all the elements will follow along.
  • Adapt the various hard coded font-sizes to use em or rem values instead of pixels.
  • Make the icons and other elements scale alongside the text to maintain a balanced UI.

Thoughts?

Flags: needinfo?(richard.marti)
Flags: needinfo?(mkmelin+mozilla)

Looks (very) good for me!

Thanks Alessandro

The hard coded font sizes aren't coded like font-size: 16px; but with font: message-box this sets the system default font with its family, size etc.

It should be possible that we either set globally something like font-size: 1.2em; or this only set on single elements like #folderTree or #threadTree. Mac may be a bit special as we set a special font on #folderTree to look more like Finder.

Flags: needinfo?(richard.marti)

(In reply to Richard Marti (:Paenglab) from comment #36)

The hard coded font sizes aren't coded like font-size: 16px; but with font: message-box this sets the system default font with its family, size etc.

It should be possible that we either set globally something like font-size: 1.2em; or this only set on single elements like #folderTree or #threadTree. Mac may be a bit special as we set a special font on #folderTree to look more like Finder.

You may also have a look of the official Apple mail application on Mac OS, which provides larger font for trees and lists.

The noticable thing is that on a mac Command-= gets a font increase (for content) in pretty much any app EXCEPT TB's message lists. It even works for the lower message pane in TB, so the critical outcome is using some measure that is susceptible to that mechanism of indicating quickly that the text is too small to read.

If that works, then many, if not all, the accessibility issues of making a bad choice are fixed, because people can zoom in to what is comfortable for them. (depending for example on ambient light/screen reflexions, whether they have their glasses on, even time of day )

First, thanks for taking this.

I don't have any thoughts on the technical approach. I do offer the following

  • Readability areas most important to me, and perhaps for others, is where content changes - message list, folder list and message preview - but mostly the first two. I personally don't need larger text in column headers and menus, and places that have icons - though I do understand it may be desirable to have the entire UI zoom at the same rate by default. If it does, then we may need to be able to control individual panes independently?
  • I would like the default keyboard zoom functionality to remain unchanged, which is to say it should only zoom the message preview, not the entire UI. If there is a desire to zoom the entire UI with a key combo then create a new one (with shift?) [interesting, on Mac command+shift+= zooms in, but command+shift+- does not zoom out - ditto on firefox]
  • Many, and perhaps most, of support requests for size control come from older and handicapped users. And based on personal experience I'd guess that in recent years many more older users are using laptops with modest sized screens, not full screen monitors.
  • To echo Mitra's comment, users are understandably surprised/disappointed that Thunderbird doesn't offer size control when most other apps do - we're way behind the curve in usability here
  • I don't know if it is wanted or needed, but toolbar has no zoom widget
  • I am concerned that larger font sizes not unduly increase whitespace between lines because vertical space is at a premium on laptops (obviously, I highly values screen real estate)

FWIW, on my MacBook Air 2012 at default resolution the message list is horribly small. I currently use the following to make it readable with screen 24" from my eyes (on Firefox I use something larger, 16, to comfortably read for hours at a time and I zoom in to 110% for example as needed)
/* Threads Pane font */
#threadTree >treechildren::-moz-tree-cell-text {
font-size: 10pt !important;
}

(In reply to Alessandro Castellani (:aleca) from comment #34)

The entire UI should be fluid, allowing users to increase/decrease font-size, alongside icons, and all the other scalable elements.

Agreed.

  • Implement a global pref to allow users controlling the global font-size. This could be achieved by adding a font-size attribute to the window style, and all the elements will follow along.
  • Adapt the various hard coded font-sizes to use em or rem values instead of pixels.

I'm not sure px vs em/rem changes things. If it does, sure. (It used to be an issue, but I think now pxs are also zoomed).

  • Make the icons and other elements scale alongside the text to maintain a balanced UI.

Yup, many icons are already svg.

Flags: needinfo?(mkmelin+mozilla)
Summary: Need larger display font for Thunderbird message list/pane and folder list/pane → Need larger display font size for Thunderbird message list/pane and folder list/pane

Folder list text may only be a couple mm high, not sure who can read that or how.

I think we have really provided the scaling of fonts requested in this bug. With the layout.css.devPixelsPerPx preference.

Sure we still have a delineation for zoom of content and scaling of the chrome, but that is a good thing in my opinion.

What is missing and has been missing for years is a user interface to allow the user to actually manage these preferences. Bug 1708595 for providing a UI for scaling user interface and something more obvious than expecting the user to know about Ctrl + and - to scale content.

How does this "pixels per pixel" setting differ from full-page zoom, with all its bugs?

For example, full-page zoom affects every single object in the same proportion. So if it doubles or triples the height of body text, it also doubles or triples the height of header text, icons, images, etc. In Firefox, by the time body text is a good readable size, header text would often be awkwardly or unreadably large, images would introduce horizontal scrolling, etc. In Thunderbird, it might work for the lists we're discussing here, but create trouble elsewhere.

See Also: → 1715364

Is it my imagination, or did recent updates to Thunderbird (I'm using 91.2.0 (64-bit) at this moment) make the main text display font a pixel smaller?

I notice that I originally commented on this 12 years ago, and as I am now well past "50", perhaps it is just me, but this seems to be a more important issue than ever, not just to me, but to the now much-more relevant issue of accessibility.

Why is it so difficult to have a font size setting for the main window with the list of messages?

Is it my imagination, or did recent updates to Thunderbird (I'm using 91.2.0 (64-bit) at this moment) make the main text display font a pixel smaller?

We didn't decrease the font size, but what do you mean by "main text display"? Is the font in the message body, or the message threads, or the folder pane, or the whole UI in general?
Would you be able to share a screenshot without any sensitive information?

Why is it so difficult to have a font size setting for the main window with the list of messages?

That's because every section of Thunderbird has its own style, with its own hardcoded CSS font size, and its own CSS file.
That's not a great situation and it makes it very hard to achieve visual consistency.
We're working towards that, we're cleaning up our styling, we implemented global UI density controls, and we're slowly expanding those options to affect the entire UI.
We have the feature to offer a global font size control for the whole UI in the roadmap.

Please do add some kind of global font size control - its been desperately needed for 12 years now, its pretty much the only app that I use that doesn't have simple keyboard control of font size.

I started working on it in this bug 1715364.
Closing this as a duplicate.

Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → DUPLICATE
No longer duplicate of this bug: 1714186
Duplicate of this bug: 1714186
You need to log in before you can comment on or make changes to this bug.