Bugzilla

hi folks! thanks for all this discussion :) it sounds like there are a few different issues at play here:

1. *On a given page, it isn't immediately obvious which content is considered _web content_ and which content is considered _browser UI_*. And because of that *it isn't clear which things should respond to zoom, and which shouldn't* (to take that one step further, perhaps: it isn't clear that FF intends to only apply zoom to web content, and not browser UI). While the "browser content" vs. "web content" distinction may be more apparent from an engineering point of view, it seems that distinction isn't carried over to our general UX. This messes with user expectations and leads to a frustrating experience overall. We have this issue when discussing the behaviour of our `about:` pages vs. the behaviour of "regular" web content, too. For example, tooltips on our `about:` pages respond to page zoom, but tooltips on "regular" web content do not. 
2. *There exists a need to customise font size on an application-by-application basis.* While (it appears) most major web browsers have similar initial font sizes, there are slight differences which may be enough for a user to need to adjust font size for a single app in particular. Users may also need individual apps to have different font sizes based on situational usage. For example, if you only use an app for a few minutes a day its default font size may be fine, but if you use an app for multiple hours a day you may need a larger font size to help avoid eye strain. The colors an app uses to render text may also impact the usable font size. Using an OS-setting alone doesn't help here. 
3. *Ease of access.* Apart from the expectations discussed in (1), page zoom is a simple, prominent, semi-universal way to adjust content size. It is exposed on every web page and isn't buried somewhere in about:preferences. This doesn't necessarily mean that page zoom should be the fix here, but I think it's something worth pointing out when we're considering alternative solutions.
4.  *Users on macOS don't have a font scaling OS setting to help here.* While windows and (I believe) linux offer specific font-scaling settings in their OS settings, macOS doesn't. Apple does expose a resolution scaling setting, but this adjusts far more than font size, and have unintended consequences. It's a rather "kitchen sink" approach to making a datalist more visible 😀 

Please let me know if I've incorrectly portrayed any of the above issues.

My thoughts: 

I think this is a valid bug. I also think page zoom is not the way to solve this issue. 
I see two possible ways forward here:
- Expose a UI scaling option somewhere (preferences, or about:config)
- Expose a UI font-scaling option somewhere (")

Based on the bug reports we've gotten related to this issue (the tooltips one comes to mind, but I believe there were others when I was working on the default-zoom stuff), I think the font-scaling option might be the place to start. 
We could consider exposing this as a checkbox in our existing font settings (about:preferences > Language and Appearance > Fonts). Something like "Apply my preferred font size to UI and web content" might be helpful? We could also nest this in the "Advanced" fonts section, near "Minimum font size", though in line with (3) above I think that might be too obscured. 

Re: how do we reconcile our setting with any OS-setting for font scaling, we could do something like what we do with the web appearance chooser when FF-HCM is enabled: expose a warning to the effect of "your other settings may conflict with this setting, so behaviour is undefined". 
I'll need to look into OS-font-scaling detection, but there's probably a system register value to check somewhere. That's how we check if OS-HCM is enabled, right now. 

I'm interested in a frontend perspective on this -- :gijs do you have thoughts? 😀

hi folks! thanks for all this discussion :) it sounds like there are a few different issues at play here:

1. **On a given page, it isn't immediately obvious which content is considered _web content_ and which content is considered _browser UI_**. And because of that *it isn't clear which things should respond to zoom, and which shouldn't* (to take that one step further, perhaps: it isn't clear that FF intends to only apply zoom to web content, and not browser UI). While the "browser content" vs. "web content" distinction may be more apparent from an engineering point of view, it seems that distinction isn't carried over to our general UX. This messes with user expectations and leads to a frustrating experience overall. We have this issue when discussing the behaviour of our `about:` pages vs. the behaviour of "regular" web content, too. For example, tooltips on our `about:` pages respond to page zoom, but tooltips on "regular" web content do not. 
2. *There exists a need to customise font size on an application-by-application basis.* While (it appears) most major web browsers have similar initial font sizes, there are slight differences which may be enough for a user to need to adjust font size for a single app in particular. Users may also need individual apps to have different font sizes based on situational usage. For example, if you only use an app for a few minutes a day its default font size may be fine, but if you use an app for multiple hours a day you may need a larger font size to help avoid eye strain. The colors an app uses to render text may also impact the usable font size. Using an OS-setting alone doesn't help here. 
3. *Ease of access.* Apart from the expectations discussed in (1), page zoom is a simple, prominent, semi-universal way to adjust content size. It is exposed on every web page and isn't buried somewhere in about:preferences. This doesn't necessarily mean that page zoom should be the fix here, but I think it's something worth pointing out when we're considering alternative solutions.
4.  *Users on macOS don't have a font scaling OS setting to help here.* While windows and (I believe) linux offer specific font-scaling settings in their OS settings, macOS doesn't. Apple does expose a resolution scaling setting, but this adjusts far more than font size, and have unintended consequences. It's a rather "kitchen sink" approach to making a datalist more visible 😀 

Please let me know if I've incorrectly portrayed any of the above issues.

My thoughts: 

I think this is a valid bug. I also think page zoom is not the way to solve this issue. 
I see two possible ways forward here:
- Expose a UI scaling option somewhere (preferences, or about:config)
- Expose a UI font-scaling option somewhere (")

Based on the bug reports we've gotten related to this issue (the tooltips one comes to mind, but I believe there were others when I was working on the default-zoom stuff), I think the font-scaling option might be the place to start. 
We could consider exposing this as a checkbox in our existing font settings (about:preferences > Language and Appearance > Fonts). Something like "Apply my preferred font size to UI and web content" might be helpful? We could also nest this in the "Advanced" fonts section, near "Minimum font size", though in line with (3) above I think that might be too obscured. 

Re: how do we reconcile our setting with any OS-setting for font scaling, we could do something like what we do with the web appearance chooser when FF-HCM is enabled: expose a warning to the effect of "your other settings may conflict with this setting, so behaviour is undefined". 
I'll need to look into OS-font-scaling detection, but there's probably a system register value to check somewhere. That's how we check if OS-HCM is enabled, right now. 

I'm interested in a frontend perspective on this -- :gijs do you have thoughts? 😀

hi folks! thanks for all this discussion :) it sounds like there are a few different issues at play here:

1. **On a given page, it isn't immediately obvious which content is considered _web content_ and which content is considered _browser UI_**. And because of that *it isn't clear which things should respond to zoom, and which shouldn't* (to take that one step further, perhaps: it isn't clear that FF intends to only apply zoom to web content, and not browser UI). While the "browser content" vs. "web content" distinction may be more apparent from an engineering point of view, it seems that distinction isn't carried over to our general UX. This messes with user expectations and leads to a frustrating experience overall. We have this issue when discussing the behaviour of our `about:` pages vs. the behaviour of "regular" web content, too. For example, tooltips on our `about:` pages respond to page zoom, but tooltips on "regular" web content do not. 
2. **There exists a need to customise font size on an application-by-application basis.** While (it appears) most major web browsers have similar initial font sizes, there are slight differences which may be enough for a user to need to adjust font size for a single app in particular. Users may also need individual apps to have different font sizes based on situational usage. For example, if you only use an app for a few minutes a day its default font size may be fine, but if you use an app for multiple hours a day you may need a larger font size to help avoid eye strain. The colors an app uses to render text may also impact the usable font size. Using an OS-setting alone doesn't help here. 
3. **Ease of access.** Apart from the expectations discussed in (1), page zoom is a simple, prominent, semi-universal way to adjust content size. It is exposed on every web page and isn't buried somewhere in about:preferences. This doesn't necessarily mean that page zoom should be the fix here, but I think it's something worth pointing out when we're considering alternative solutions.
4.  **Users on macOS don't have a font scaling OS setting to help here.** While windows and (I believe) linux offer specific font-scaling settings in their OS settings, macOS doesn't. Apple does expose a resolution scaling setting, but this adjusts far more than font size, and have unintended consequences. It's a rather "kitchen sink" approach to making a datalist more visible 😀 

Please let me know if I've incorrectly portrayed any of the above issues.

My thoughts: 

I think this is a valid bug. I also think page zoom is not the way to solve this issue. 
I see two possible ways forward here:
- Expose a UI scaling option somewhere (preferences, or about:config)
- Expose a UI font-scaling option somewhere (")

Based on the bug reports we've gotten related to this issue (the tooltips one comes to mind, but I believe there were others when I was working on the default-zoom stuff), I think the font-scaling option might be the place to start. 
We could consider exposing this as a checkbox in our existing font settings (about:preferences > Language and Appearance > Fonts). Something like "Apply my preferred font size to UI and web content" might be helpful? We could also nest this in the "Advanced" fonts section, near "Minimum font size", though in line with (3) above I think that might be too obscured. 

Re: how do we reconcile our setting with any OS-setting for font scaling, we could do something like what we do with the web appearance chooser when FF-HCM is enabled: expose a warning to the effect of "your other settings may conflict with this setting, so behaviour is undefined". 
I'll need to look into OS-font-scaling detection, but there's probably a system register value to check somewhere. That's how we check if OS-HCM is enabled, right now. 

I'm interested in a frontend perspective on this -- :gijs do you have thoughts? 😀

hi folks! thanks for all this discussion :) it sounds like there are a few different issues at play here:

1. **On a given page, it isn't immediately obvious which content is considered _web content_ and which content is considered _browser UI_**. And because of that *it isn't clear which things should respond to zoom, and which shouldn't* (to take that one step further, perhaps: it isn't clear that FF intends to only apply zoom to web content, and not browser UI). While the "browser content" vs. "web content" distinction may be more apparent from an engineering point of view, it seems that distinction isn't carried over to our general UX. This messes with user expectations and leads to a frustrating experience overall. We have this issue when discussing the behaviour of our `about:` pages vs. the behaviour of "regular" web content, too. For example, tooltips on our `about:` pages respond to page zoom, but tooltips on "regular" web content do not. 
2. **There exists a need to customise font size on an application-by-application basis.** While (it appears) most major web browsers have similar initial font sizes, there are slight differences which may be enough for a user to need to adjust font size for a single app in particular. Users may also need individual apps to have different font sizes based on situational usage. For example, if you only use an app for a few minutes a day its default font size may be fine, but if you use an app for multiple hours a day you may need a larger font size to help avoid eye strain. The colors an app uses to render text may also impact the usable font size. Using an OS-setting alone doesn't help here. 
3. **Ease of access.** Apart from the expectations discussed in (1), page zoom is a simple, prominent, semi-universal way to adjust content size. It is exposed on every web page and isn't buried somewhere in about:preferences. This doesn't necessarily mean that page zoom should be the fix here, but I think it's something worth pointing out when we're considering alternative solutions.
4.  **Users on macOS don't have a font scaling OS setting to help here.** While windows and (I believe) linux offer specific font-scaling settings in their OS settings, macOS doesn't. Apple does expose a resolution scaling setting, but this adjusts far more than font size, and have unintended consequences. It's a rather "kitchen sink" approach to making a datalist more visible 😀 

Please let me know if I've incorrectly portrayed any of the above issues.

My thoughts: 

I think this is a valid bug. I also think page zoom is not the way to solve this issue. 
I see two possible ways forward here:
- Expose a UI scaling option somewhere (preferences, or about:config)
- Expose a UI font-scaling option somewhere (")

Based on the bug reports we've gotten related to this issue (the tooltips one comes to mind, but I believe there were others when I was working on the default-zoom stuff), I think the font-scaling option might be the place to start. 
We could consider exposing this as a checkbox in our existing font settings (about:preferences > Language and Appearance > Fonts). Something like "Apply my preferred font size to UI and web content" might be helpful? We could also nest this in the "Advanced" fonts section, near "Minimum font size", though in line with (3) above I think that might be too obscured. 

Re: how do we reconcile our setting with any OS-setting for font scaling, we could do something like what we do with the web appearance chooser when FF-HCM is enabled: expose a warning to the effect of "your other settings may conflict with this setting, so behaviour is undefined". 
I'll need to look into OS-font-scaling detection, but there's probably a system registry value to check somewhere. That's how we check if OS-HCM is enabled, right now. 

I'm interested in a frontend perspective on this -- :gijs do you have thoughts? 😀