Open Bug 1347169 Opened 6 years ago Updated 4 years ago

Allow chrome UI to be enlarged or shrunk using a manifest property


(WebExtensions :: Frontend, enhancement, P3)



(Not tracked)


(Reporter: mikedeboer, Unassigned)


(Blocks 1 open bug)


(Whiteboard: triaged)

User Story

As a theme author I’d like to set a property in a theme WebExtension manifest that will allow the chrome UI to be enlarged or shrunk when set during runtime and web pages inside tabs are not, because their their zoom level can be controlled separately using page zoom.
If this is not possible, we can also allow content and chrome to scale together (limited to .9x, 1x, 1.1x for example)


(2 files)

No description provided.
Priority: -- → P5
Severity: normal → enhancement
mass move of existing themes bugs to new WebExtensions: Themes component
Component: WebExtensions: Frontend → WebExtensions: Themes
Duplicate of this bug: 1437343
Product: Toolkit → WebExtensions
I talked with Tim about this bug and we think that this doesn't make sense as part of the Theming API since it feels like more of an accessibility feature and the theming API also has abilities to set themes on a per-window basis which doesn't make as much sense for this.

We think that the browserSettings namespace is a better fit.

Mike, are you okay with changing the namespace on this? Tim can begin working on this now, if so.
Assignee: nobody → ntim.bugs
Component: Themes → Frontend
Flags: needinfo?(mconca)
Priority: P5 → P1
Thanks, Jared. I agree with taking this out of themes. I'd like to pause before putting it into browserSettings, though. Two reasons:

1) There are a few other proposed accessibility-related API, enough that we've been discussing creating a new namespace just for them. This would fit into that namespace.

2) This API replicates a function already found in most (all?) OS's, and we've explicitly been avoiding adding WebExtension API that duplicate functionality already available.

Regarding #2, I know the accessibility team has been making an effort to have Firefox inherit and use more OS functionality, rather than implement accessibility features into the product. I'd like to get David Bolter's opinion on if there is value in letting extensions change the size of the Firefox chrome UI.
Flags: needinfo?(mconca) → needinfo?(dbolter)
Priority: P1 → P3
Thanks Mike.

Aside: as a general comment we do have a history of trying to inherit os functionality, and yet I think we can sometimes do better than the os (e.g. Windows High Contrast Mode is not right for the web). My gut says there is value in letting extensions change the chrome UI but it also feels like it could be misused.

I'm going to redirect this question to Jamie, our newish engineering manager for accessibility, for further thoughts/delegation.
Flags: needinfo?(dbolter) → needinfo?(jteh)
There are two parts to "inheriting" OS accessibility functionality: 1) whether the OS implementation of that functionality actually has any impact on Firefox and 2) whether we respect the OS accessibility settings. They are related, but different.

1. Because Firefox renders pretty much all of its own widgets (we don't use native OS widgets), we don't just get most visual accessibility tweaks from the OS "for free". For example, if you turn on high contrast, without specific code in Firefox, it's not going to have any impact. (We do have specific code for that, but it's somewhat broken on the modern web as David noted. That's out of scope here, though.)
2. Despite that, once we do have code for a specific a11y tweak, we can still choose to tie that tweak to the OS setting; e.g. if the user set high contrast in Windows, let's turn on Firefox high contrast.

So, in talking about functionality to enlarge/shrink the chrome, we need to consider two things:
1. Does Firefox even support this at all? I'm not sure of the answer to this question. Certainly, I don't think we get this for free from the OS, unless they're running magnifier or similar (overkill for many users), and even if they were, it would be less optimal (pixelation, etc.).
2. How does someone enable it? here, you could either say "there's an OS setting for that and we should respect it", "let's add a WebExtension API", or both.

I think we need an answer from the reporter as to why, for example, the Windows 10 Settings -> Ease of Access -> Display -> Change the size of apps and text on the main display isn't sufficient. And if the answer is that there's a desire to make the Firefox UI bigger but not other things on the system, why?

The other thing to keep in mind, though, is that the needs of users with vision impairments are *incredibly* varied. It's possible that respecting OS settings just doesn't give some users the kind of customisation they need. High contrast is a good example of this. In Windows, it's more or less an on/off setting, but the most comfortable implementation depends on the user's needs, and on/off just might not be enough to provide for this. In those cases, allowing add-on authors to customise this makes a lot of sense: we can't implement settings to suit every possible need, but if add-ons have the power to do what is needed, we can still "help" those users.

NI Eitan because he'll probably have some additional thoughts and his expertise/context in this area is far greater than mine.
Flags: needinfo?(jteh) → needinfo?(eitan)
The case (sales-pitch) for the feature

It's desired and useful
Until the end of XUL add-ons, Theme Font & Size Changer was a popular add-on maintaining 100K+ users year after year and it was a featured add-on several times.
Enlarging the UI was my concept back in 2005 and no one wanted to touch it because they didn't see a need or use for it ("the OS does that" was one excuse). Baris Derin eventually developed it.

I am legally blind but I do not use (many) Windows accessibility features because they're not great and I have developed content for the masses and not just for those with disabilities and so I need(ed) to see things as they did even if it meant struggles for myself.

I've received many emails over the years from users with visual impairments, elderly individuals, and others thanking and praising us for the add-on. When the add-on worked properly, the reviews on the add-on's page were very positive and appreciative.

Extra appeal
While it was never intended, Theme Font & Size Changer became very popular with general Firefox users too (with no visual or other issues), who used HD large screens, dual monitors, and Hi-Res settings overall on various monitors. I myself use a 32" TV as a monitor. 
For what it's worth, layout.css.devPixelsPerPx isn't a good alternative since it enlarges everything. 

It's doable
Vivaldi implemented UI scaling (as a default feature) and touts it as a feature (we suspect as a result of Theme Font & Size Changer's popularity, reviews, and usefulness). I've never looked into it and I don't have the expertise to anyway, but I believe that Vivaldi uses Chromium so perhaps looking into it would be helpful for implementing the feature into Firefox.

I know that the number of users of accessibility features, add-ons, apps, etc are low in comparison, but, we all still try to take care of users with greater issues who are simply trying to use the Internet with fewer struggles. This feature help with that.
And like I said above, it appeals to different Firefox users for different reasons.
Attached image Reviews 1
Attached image Reviews 2
Thanks Ken for all of that context, that is very useful.

Some unordered thoughts:

1. Ideally, yes.. "the OS does that" should be good enough, but it is pretty obvious that many users are introduced to large font UIs through extensions like Ken's, and that is a good thing.

2. I'm not sure the best namespace to fit this in, but I think this would be useful both as an API and manifest key for lightweight themes.

3. Some thought needs to be put into the max font size, since at some point it will severely break the UI and not leave the user with an easy way to undo it.

4. Currently, Firefox's UI is pretty bad at scaling the icons along with the fonts. That is unfortunate since we rely on visual language much more than text in the UI. It would be cool if some work was put into icon scaling.
Flags: needinfo?(eitan)
Assignee: ntim.bugs → nobody
You need to log in before you can comment on or make changes to this bug.