1715364 - Add a UI to set a default UI font size

Status: RESOLVED FIXED

(Thunderbird :: Mail Window Front End, enhancement, P2)

Description

[Richard Marti (:Paenglab)]

We should add a UI to set the base font size of the UI. When we set the font size on :root this would work really good. Only some widget have set a font: some system font; which then would need an override like font-size: inherit;.

Comment 1

[Richard Marti (:Paenglab)]

Alessandro, what do you think where and how should the UI reside for the font size? Something like the density setting in menu or in the prefs? And how should we show it, a slider to set the size or a normal number text box or a menulist. I think we should set some minimum and maximum size to not let the user set excessive sizes.

Comment 2

[Alessandro Castellani [:aleca]]

Indeed, we need to properly define how to approach this as there are many moving pieces that could get out of hand quickly.

Technical implementation
Setting the font-size on the :root element is the way to go as you suggested.
What would that default font size be? We should inherit the System font size, right? In order to let TB properly adapt to any current font scaling the user has set on his computer.

Should this new :root style also affect the Message Pane? Or should that be independent?

For the various areas where we have defined a fixed font size, we should update it to use rem in order to maintain the defined size but making it relative to the root item, so if the user scales the root font size, every other widget scales up and down accordingly.

Preferences
We have a bunch of places where the user can define the font:

• Preferences > General > Language & Appearance. (as well as the Advanced dialog with more granular control)
• Preferences > Composition > HTML Style (This affects only the composition but not the message view)
• Main Menu and App Menu > View > Zoom (This can affect both composition and message view, but it's not linked together)

These options affect different areas of the application but they feel kind of interchangeable.
We should clean up a little bit these options and be sure that they make sense and are easy to understand and find.

Comment 3

[Alessandro Castellani [:aleca]]

This might be a duplicated of bug 570442, or maybe not entirely.

Comment 4

[Magnus Melin [:mkmelin]]

From that bug, there is also layout.css.devPixelsPerPx , which I'm not sure how/if it should play into this mix.

Preferences > General > Language & Appearance.

These are complicated, but inherited from the platform so better not change them.
I think beneath these would be an appropriate place to put some scaling option.

Preferences > Composition > HTML Style

This is for the fonts sent out. I would suggest dropping this one: you don't have happy recipients when some set the default font to huge to better see what they themselves are composing (when they should be using zoom instead).

Comment 5

[Magnus Melin [:mkmelin]]

... as could happen e.g. on the ux-list ;)

Comment 6

[Richard Marti (:Paenglab)]

(In reply to Alessandro Castellani [:aleca] from comment #2)

Indeed, we need to properly define how to approach this as there are many moving pieces that could get out of hand quickly.

Technical implementation
Setting the font-size on the :root element is the way to go as you suggested.
What would that default font size be? We should inherit the System font size, right? In order to let TB properly adapt to any current font scaling the user has set on his computer.

Ye, when the user hasn't touched or resetted the setting, we shouldn't set a base font size.

Should this new :root style also affect the Message Pane? Or should that be independent?

Yes, on every window. We set the base font size and not one for every special area.

For the various areas where we have defined a fixed font size, we should update it to use rem in order to maintain the defined size but making it relative to the root item, so if the user scales the root font size, every other widget scales up and down accordingly.

You can try in Inspector on the <html:body>, the :root, to set a font size and see how it works on this window.

(In reply to Magnus Melin [:mkmelin] from comment #4)

From that bug, there is also layout.css.devPixelsPerPx , which I'm not sure how/if it should play into this mix.

This setting scales the whole UI with the toolkit scaling quirks Alex knows best ;-) . The font size only makes the fonts bigger/smaller without for example scaling the icons.

Comment 7

[alta88]

1. The only way to do this correctly (simple for users) is to use a zoomlevel scaling, and not by fiddling with font size.
2. There has to be a distinction between chrome and content (messagepane, contentTab).
3. Using devPixelsPerPx is correct for global sizing (both chrome and content) and applies to non text UI like tree lists and toolbars and icons and menulists; if this is changed there must also be a proportionate scaling of the baseline font size, programmatically and not by user guesswork in a UI. This global zoom level would be user settable in Preferences.
4. As in Fx, content scaling should be independently zoomable and be persisted, per tab. This scaling is applied on top of the global zoom level. It should be settable via ctrl +/- or ctrl-mousewheel on content. An even nicer thing would be to have "site" level zoom (which for email might mean sender as well as domain - prior art there is remote content preferences).

An attempted implementation of the above can be found in BrowseInTab.

Comment 8

[atbest]

Attachment: main

Comment 9

[atbest]

Attachment: preference

Comment 10

[atbest]

Attachment: config

Comment 11

[atbest]

I agree that devPixelsPerPx is a good option to use, but please be aware of the differences of font size between the main tab (message list etc) and the preferences tab with the same devPixelsPerPx value.
In my opinion, the font size implementation of the main tab should follow that of the preference tab, and then all we need is to add something to change the zoom level, which is devPixelsPerPx internally.

Comment 12

[Alessandro Castellani [:aleca]]

I've been looking into this a little bit and I think I have a possible solution that will make the whole UI more consistent.

First, we should use the devPixelsPerPc as that scales the UI outside our control, adding inconsistencies and weird edge cases for HiDPI monitors and scaled up font.

UI scaling
For that, we implemented the UIDesnity option, which gives us full control on how to properly scale the UI and which areas are affected. We need to expand on that and make that option "leak" in more areas to better scale everything accordingly.

Font scaling
We need to hook it to the Zoom overlay we currently use for the compose area, in order to have a single zoom option that affects all fonts and not just the compose or message area.
Having 2 different controls, one for the compose/read message, and on for the UI would be very confusing and not really useful.

We should expand this method in order to affect the body element of every tab and window: https://searchfox.org/comm-central/rev/c77102402f9ddb2742f6782aa5b73362be39d5f5/mail/base/content/viewZoomOverlay.js#62

• Setting a font-size: 100% to the body will make the whole UI follow the system font size.
• When the zoom changes, we can increase/decrease the font-size attribute by 10%.
• We need to remove any hard coded px font sizing from various areas and convert them into em to allow proper resizing.

I have a rough patch for this and it seems to work fine.
Does anyone see any downfalls or issues from this?

Comment 13

[Alessandro Castellani [:aleca]]

Attachment: bug1715364-zoom-ui.diff

Quick rough WIP patch to explore this solution.
Dirty little trick to add font-size % inline styling to the current document body.
The scaling is not maintained on restart because we don't store the zoom level anywhere, that's also why newly opened windows or tabs don't inherit the font scaling, but that's something for later.

How does this feel?

Comment 15

[Matt]

Are we reinventing the wheel here?
layout.css.devPixelsPerPx is the accepted scaling pref for platform, and setting it 1.25 scales the UI to 125% 1.5 to 150% etc. and has been widely recommended and used especially with mac users for several releases now. While there are some issues with larger percentages with text not fitting in the space allotted, that appears to be the case regardless of the sizing method used.

Having set out fonts in preferences in such a way users assume they have impacts they do not has exacerbated the lack of user interface elements for setting them. But approaching this with using the existing mechanisms and preferences is a starting point that does not require rebuilding the UI using global stylesheets just yet shold be a first step.

The issue of a globaL stylesheet is one for another bug as it will be a major task in itself.

Comment 16

[Roger Wagner]

Do you mean being able to press Cmd+/-? I'm still using Mac OS X 10.12.6 (I know, I know); Cmd +/- doesn't affect the display size.

Comment 17

[Matt]

(In reply to Roger Wagner from comment #16)

Do you mean being able to press Cmd+/-? I'm still using Mac OS X 10.12.6 (I know, I know); Cmd +/- doesn't affect the display size.

Use the config editor https://support.mozilla.org/en-US/kb/config-editor
change the preference layout.css.devPixelsPerPx ito 1.25 try it for size if it is still to small change it to 1.5 and try that out. Just make sure you make small changes at a time as making the whole thing huge and unworkable is also possible.

Comment 18

[Alessandro Castellani [:aleca]]

(In reply to Roger Wagner from comment #16)

Do you mean being able to press Cmd+/-? I'm still using Mac OS X 10.12.6 (I know, I know); Cmd +/- doesn't affect the display size.

Yes, with the approach I'm thinking about adopting, pressing Cmd+/- will increase the font size of the whole UI.

(In reply to Matt from comment #15)

Are we reinventing the wheel here?

Not reinventing anything as what I'm proposing is using existing features, UI menu items, and code.

layout.css.devPixelsPerPx is the accepted scaling pref for platform...

As I wrote before, using that pref is not recommended since it doesn't allow us to properly control the outcome as it scales the whole UI, causing problems with HiDPI displays at specific resolutions.

Having set out fonts in preferences in such a way users assume they have impacts they do not has exacerbated the lack of user interface elements for setting them.

I'm not rebuilding anything as using the Zoom In and Zoom Out would feel pretty natural and expected. Like every program out there, when you use the Zoom In menu item, or hit Ctrl+, you expect the whole font to grow, and the UI should scale to accommodate the font size.

The issue of a globaL stylesheet is one for another bug as it will be a major task in itself.

I disagree.
First, I'm not proposing a global stylesheet approach, even tho we already have messenger.css which is basically used and loaded anywhere, second, what I'm proposing is a proper clean up in our stylesheet which will bring visual consistency across the application.

Aiming for quick fixes or band-aids to offer a feature is never a good idea. It's better to do things properly and find solid solution that can scale with time, and simply exposing layout.css.devPixelsPerPx is not a good solution.

Anyway, did you try my WIP patch? It's a pretty simple implementation which does the trick and uses existing UI elements.
Nothing is set in stone nor has been decided, that's why I've asked for feedback on a simple WIP patch.

Comment 19

[atbest]

I would like to try your WIP patch, but unfortunately I don't know how to do it. Would you please provide a full installer with your fix?

Anyway, did you try my WIP patch? It's a pretty simple implementation which does the trick and uses existing UI elements.
Nothing is set in stone nor has been decided, that's why I've asked for feedback on a simple WIP patch.

Comment 20

[Richard Marti (:Paenglab)]

I'm not sure if we should use the zoom to scale the UI. Clearly it's easy to use but is this something the user would change many times? It also interferes with the message content zoom. If you're okay with the UI font sizes and want to only zoom the message content it's no more possible with the keyboard only. It changes also the UI and shrinks the viewport of the message. This works only with the mouse wheel. And it seems we need to wait until the old tree widget is removed because this one doesn't scale despite we use em for the min-height.

Not sure if it should but on the calendar tabs it doesn't work.

Comment 21

[Alessandro Castellani [:aleca]]

(In reply to atbest from comment #19)

I would like to try your WIP patch, but unfortunately I don't know how to do it. Would you please provide a full installer with your fix?

I'll create a test build later on once things are bit more refined :D

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

I'm not sure if we should use the zoom to scale the UI. Clearly it's easy to use but is this something the user would change many times?

That's a matter of deciding if we want to create a stricter separation between chrome and content. Something to consider and to think about it.

It also interferes with the message content zoom. If you're okay with the UI font sizes and want to only zoom the message content it's no more possible with the keyboard only. It changes also the UI and shrinks the viewport of the message.

For this, we should consider the various use cases and see if it makes sense keeping the zoom of the content separated from the zoom of the chrome. We should ask ourselves and our users some questions, like why we might need to zoom the message content on occasions, and if it's really used for specific scenarios rather than just being there as a feature that wasn't entirely thought through.

And it seems we need to wait until the old tree widget is removed because this one doesn't scale despite we use em for the min-height.

Oh yeah, whatever direction we go, it will need a lot of progressive iterations and changes across the app.

Not sure if it should but on the calendar tabs it doesn't work.

Nope, this wip patch only affect the mail tab, I ignored everything else as this is just a proof of concept.

Comment 22

[atbest]

(In reply to Alessandro Castellani [:aleca] from comment #21)

It also interferes with the message content zoom. If you're okay with the UI font sizes and want to only zoom the message content it's no more possible with the keyboard only. It changes also the UI and shrinks the viewport of the message.

For this, we should consider the various use cases and see if it makes sense keeping the zoom of the content separated from the zoom of the chrome. We should ask ourselves and our users some questions, like why we might need to zoom the message content on occasions, and if it's really used for specific scenarios rather than just being there as a feature that wasn't entirely thought through.
I can see the differences between the zoom of content and the zoom of chrome. The zoom of chrome should be relatively stable once it is set for a specific monitor, but the message content may require different zoom occasionally. For example, when the font or viewport of a message is set to very small or very large by the sender.
This is actually how Firefox works as show in the following image. When zooming in or out, you only zoom the webpage, but not the browser chrome. The chrome can only be zoomed with layout.css.devPixelsPerPx.

Comment 23

[atbest]

Attachment: firefox zoom

Comment 24

[atbest]

(In reply to Alessandro Castellani [:aleca] from comment #21)

It also interferes with the message content zoom. If you're okay with the UI font sizes and want to only zoom the message content it's no more possible with the keyboard only. It changes also the UI and shrinks the viewport of the message.

For this, we should consider the various use cases and see if it makes sense keeping the zoom of the content separated from the zoom of the chrome. We should ask ourselves and our users some questions, like why we might need to zoom the message content on occasions, and if it's really used for specific scenarios rather than just being there as a feature that wasn't entirely thought through.

I can see the differences between the zoom of content and the zoom of chrome. The zoom of chrome should be relatively stable once it is set for a specific monitor, but the message content may require different zoom occasionally. For example, when the font or viewport of a message is set to very small or very large by the sender.

This is actually how Firefox works as show in the image above. When zooming in or out, you only zoom the webpage, but not the browser chrome. The chrome can only be zoomed with layout.css.devPixelsPerPx.

Comment 25

[Alessandro Castellani [:aleca]]

I can see the differences between the zoom of content and the zoom of chrome. The zoom of chrome should be relatively stable once it is set for a specific monitor, but the message content may require different zoom occasionally. For example, when the font or viewport of a message is set to very small or very large by the sender.

Indeed, that's a valid distinction and I think we should definitely keep it.

This is actually how Firefox works as show in the image above. When zooming in or out, you only zoom the webpage, but not the browser chrome. The chrome can only be zoomed with layout.css.devPixelsPerPx.

Sure, but as I said we shouldn't use that pref.
That pref is specifically used, and should be used, for integer pixel doubling for HiDPI monitors. That pref should be used for values like 1 or 2 to double up the pixel density in 4k+ monitors.
Introducing fractional scaling is very bad as we would have no control at all on the outcome of the interface. Things like icons might end up with a stroke thickness of 1.35px, which the pixels in your monitor will try to round up to blurry 2px.

What I'm saying is, that preference affects the entire interface, including images, icons, borders, margins, gradients, as well as the font, but what we need is something to exclusively control the font sizing as a specific accessibility feature.
Users with 4K+ monitors can use that pref to manipulate the interface in case Thunderbird doesn't adapt properly to the Operating System display settings, but even if the font size is affected by it for obvious reasons, we (as developers) shouldn't rely on that to offer accessibility control for the font size as it scales everything up with weird outcomes, and we can't guarantee proper interface rendering.

Comment 26

[Matt]

You say we should not use this preference, I can accept that. So why are we not fixing the problem, which appears to be the code is not capable of detecting a monitor change on new video setups, or migrating the profile to new hardware. Many many posts have been made in support forums asking to offer manual scaling, but the vast majority are based on defective auto detection of same. It is my contention that the user demand is made to cover failure of the software to scale correctly with the human response of "I need to make this stuff bigger". Usually the conversation includes reference to the windows accessibility features for scaling the UI and the response is other applications work as expected. Thunderbird is the only program affected.

The Mozilla platform and hence Thunderbird has a problem, and we are papering over it with either approach. What is wrong that we can not just detect a change and adjust scaling to suit automatically, but it is apparent we can not. This has been show over and over with new profiles offering distinctly different scaling in the display. So apparently the software can detect what it needs to use, but it only happens on profile creation or something.

Comment 27

[Alessandro Castellani [:aleca]]

The Mozilla platform and hence Thunderbird has a problem, and we are papering over it with either approach. What is wrong that we can not just detect a change and adjust scaling to suit automatically, but it is apparent we can not.

I agree with you on this, I think the platform should try as much as possible to autodetect the current display resolution and scale accordingly.
Personally, I wouldn't be against exposing UI scaling in the preferences. Do we already have a bug for it? We can definitely continue this discussion there and find a saner implementation.

So, to quickly recap, we're kinda moving towards this:

• UI Desnity: Controls spacing like margin and paddings, as well as line height and row height of elements. Also Increases icons and buttons sizes for touch interfaces without affecting the font.
• layout.css.devPixelsPerPx: Controls the entire UI scaling, literally increasing the number of pixels rendered for the entire application. Necessary to fix monitor scaling and HiDPI issues for various platforms and resolutions.
• Zoom In/Out: Controls the font sizing of the message content and web pages, and only that.
• Something new?: Controls the font sizing of the whole application.

So, maybe for that "something new" we can approach it with what Magnus suggested in comment 4:

Preferences > General > Language & Appearance.

These are complicated, but inherited from the platform so better not change them.
I think beneath these would be an appropriate place to put some scaling option.

And for the type of implementation, we could go with what I suggested (AKA having a font-size 100% styling added to the body and fixing the CSS to update accordingly).

Comment 28

[Magnus Melin [:mkmelin]]

Comment on attachment 9245053 [details] [diff] [review]
bug1715364-zoom-ui.diff

Review of attachment 9245053 [details] [diff] [review]:
-----------------------------------------------------------------

I think this feels pretty good, and seems like a good direction (regardless of other prefs).

Comment 29

[Alessandro Castellani [:aleca]]

Nice, thanks for the feedback.
I think we could potentially keep the separation between content and chrome.
Let's focus on a small and targeted implementation that we can slowly expand with time.

This is what I'm thinking as a first patch:

• Create a mail/modules/FontScaling.jsm.
• Create a pref("mail.fontscaling", 1); to store the preferred font sizing.
• The FontScaling.jsm should be slowly included in those tabs that need it, starting with the primary Mail Tab for now.
• The FontScaling.jsm could maybe listen for newly opened windows and dialogs in order to apply the font scaling to those, so we don't need to add that module to every xhtml file, but only the "main" tabs.

Comment 30

[Alessandro Castellani [:aleca]]

Attachment: Bug 1715364 - Add a UI font size preference for the mail tab. r=mkmelin

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/7366bbb3868a
Add a UI font size preference for the mail tab. r=mkmelin

Comment 32

[atbest]

Please also consider altering line height for message list and accout/folder list when adjusting font size.

Comment 33

[atbest]

BTW, I found a pref font.size.systemFontScale that can be used to scale font size everywhere.

Comment 34

[atbest]

(In reply to Alessandro Castellani [:aleca] from comment #27)

So, to quickly recap, we're kinda moving towards this:

• UI Desnity: Controls spacing like margin and paddings, as well as line height and row height of elements. Also Increases icons and buttons sizes for touch interfaces without affecting the font.
• layout.css.devPixelsPerPx: Controls the entire UI scaling, literally increasing the number of pixels rendered for the entire application. Necessary to fix monitor scaling and HiDPI issues for various platforms and resolutions.
• Zoom In/Out: Controls the font sizing of the message content and web pages, and only that.
• Something new?: Controls the font sizing of the whole application.
  It seems that Thunderbird cannot remember the zoom level of the message content before close. We need some mechanism to set and save a default zoom level for all messages as Firefox did.

Comment 35

[atbest]

(In reply to Alessandro Castellani [:aleca] from comment #27)

So, to quickly recap, we're kinda moving towards this:

• UI Desnity: Controls spacing like margin and paddings, as well as line height and row height of elements. Also Increases icons and buttons sizes for touch interfaces without affecting the font.
• layout.css.devPixelsPerPx: Controls the entire UI scaling, literally increasing the number of pixels rendered for the entire application. Necessary to fix monitor scaling and HiDPI issues for various platforms and resolutions.
• Zoom In/Out: Controls the font sizing of the message content and web pages, and only that.
• Something new?: Controls the font sizing of the whole application.

It seems that Thunderbird cannot remember the zoom level of the message content before close. We need some mechanism to set and save a default zoom level for all messages as Firefox did.

Comment 36

[Alessandro Castellani [:aleca]]

Please also consider altering line height for message list and accout/folder list when adjusting font size.

Yes, we're taking care of that in bug 1717695.

BTW, I found a pref font.size.systemFontScale that can be used to scale font size everywhere.

That's a pref coming from Firefox which is not hooked to anything on our hand and we don't use it.
We try to avoid relying on Firefox prefs since they can be deprecated and removed.

It seems that Thunderbird cannot remember the zoom level of the message content before close. We need some mechanism to set and save a default zoom level for all messages as Firefox did.

Yup, I'm aware of that, but that's an issue for another bug

Comment 37

[Matt]

Attachment: setting font.size.systemFontScale to 125 V's default 100

(In reply to Alessandro Castellani [:aleca] from comment #36)

Please also consider altering line height for message list and accout/folder list when adjusting font size.

Yes, we're taking care of that in bug 1717695.

BTW, I found a pref font.size.systemFontScale that can be used to scale font size everywhere.

That's a pref coming from Firefox which is not hooked to anything on our hand and we don't use it.
We try to avoid relying on Firefox prefs since they can be deprecated and removed.

I suggest you try it :aleca I just did on my trusty nightly and after a restart all fonts used were scaled to the 125 that I set. So perhaps we are relying on in these preferences after all. What I do know is I keep being told that we should reuse mozilla development resources if we can, I see no reason to just recreate scaling if the platform supports it.

Comment 38

[atbest]

(In reply to Alessandro Castellani [:aleca] from comment #36)

It seems that Thunderbird cannot remember the zoom level of the message content before close. We need some mechanism to set and save a default zoom level for all messages as Firefox did.

Yup, I'm aware of that, but that's an issue for another bug

OK, I found the bug report four years ago bug 1373187, along with several other reports. Since Firefox has resolved this problem with the default zoom setting, maybe it is not difficult to fix?

Comment 39

[Alessandro Castellani [:aleca]]

(In reply to Matt from comment #37)

I suggest you try it :aleca I just did on my trusty nightly and after a restart all fonts used were scaled to the 125 that I set. So perhaps we are relying on in these preferences after all.

That preference is used by gecko in the m-c repo only for the android mobile version, and we can't change that code since what's good for TB most of the times is not good for FF.
I'm actually pretty surprised that pref is doing anything on desktop o_O
Also, that pref only kicks in on restart, so the user won't see any change and for every small variation they will need to restart TB, and that's horrible UX :D

What I do know is I keep being told that we should reuse mozilla development resources if we can, I see no reason to just recreate scaling if the platform supports it.

Sure, "reusing m-c dev resources" is the base approach we all follow, but there are scenarios in which we can't, it doesn't make sense, and it's potentially dangerous.
In this case:

• m-c won't accept changesets pushed to their code that make the use of that pref larger than it was originally designed for
• using that pref in TB is very dangerous since that's not a desktop pref (from the code it seems only android specific) and we can't base our entire UI font scaling on a pref we have no control over
• Firefox has very little UI, with their font scaling purely focusing on content, while Thunderbird has pretty much all chrome (even tho we kinda handle it like content), so we have different needs and objectives

So, as you can see there are many many factors to consider, and is not as simple as "there's a pref from m-c, let's just use that".

Comment 40

[Alessandro Castellani [:aleca]]

Attachment: Bug 1715364 - Implement font scaling menu items.r=mkmelin,darktrojan,Paenglab

Comment 41

[Alessandro Castellani [:aleca]]

Attachment: font-size.png

Second patch for this feature.
This one takes care of implementing a first UI control in the Main App Menu.

• No control in the menu bar, that will come later.
• No shortcuts for those controls, those will come later.
• So far it work only on the primary mail tab, other tabs will be integrated later.

Here's some explanations about this implementation in the form of FAQ might arise from it.

Why not using the existing zoom?
Because the mail content and the UI should scale independently as the UI has a "fixed" necessity (users set the font once to their necessities and don't touch it again) where the mail content can be commonly zoomed in and out to account for weirdly formatted emails.

Why not using a Zoom % type of UI
Because that would mean masking the actual font size to the user, and scaling with % might result into a weird subpixel font size we can't control.
Showing the actual font size will help users to make a better educated decision against the font size of their OS, and better distinguish this feature from the Zoom Content feature.

Why not showing this in the main panel view instead of the View submenu
Other than the main panel view being pretty full already, this feature is not something users will use every day and they need to access constantly. This is a feature that users might need to touch once or twice to set their favorite font size and than no more.
It lives on the same level as the UI Density because these 2 features are goal adjacent.

Comment 42

[MarjaE]

Ran into this while using troubleshoot mode. If I use the minimum resolution/largest size for my monitor, then message list fonts are still only 2 mm high, and unreadable from more than 30.5 cm/12" away.

Other font sizes vary a great deal, so pixels per-pixel won't put everything at a good size at the same time.

Comment 43

[Alessandro Castellani [:aleca]]

Leaving this open since it needs some tests to cover the feature.

Comment 44

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/97918d20311c
Implement font scaling menu items. r=mkmelin,darktrojan,Paenglab

Comment 45

[Richard Marti (:Paenglab)]

Attachment: Bug 1715364 - Make the Font size buttons density aware. r=aleca

Comment 46

[Alessandro Castellani [:aleca]]

Attachment: Bug 1715364 - Fix line height issues when hovering over an address book list item. r=darktrojan

Comment 47

[Geoff Lankow (:darktrojan)]

Attachment: Bug 1715364 - Fix address book test clicking on the wrong row. r=aleca

Due to rounding, this test has been incorrectly passing since it was written.

Comment 48

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/bc49a4bab111
Fix address book test clicking on the wrong row. r=aleca
https://hg.mozilla.org/comm-central/rev/7a19deee6915
Fix line height issues when hovering over an address book list item. r=darktrojan

Comment 49

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/comm-central/rev/a20735939d91
Make the Font size buttons density aware. r=aleca

Comment 50

[Alessandro Castellani [:aleca]]

Closing this as the majority of the initial work has been done.
Future work and fixes will be done in follow ups.