Closed Bug 1288917 Opened 8 years ago Closed 7 years ago

Add an API to allow toggling 'use system colors' preference

Categories

(WebExtensions :: General, defect, P3)

49 Branch
x86
Unspecified
defect

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: bugzilla12345678, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: triaged)

Attachments

(1 file)

Attached image del.PNG
User Agent: Mozilla/5.0 (Windows NT 5.1; rv:32.0) Gecko/20100101 Firefox/32.0
Build ID: 20140911151253

Steps to reproduce:

Some people (including me) who has some disability with eyes or maybe even healthy users would welcome some simply fication when switching from System colors to CSS Injected styles uses by addons like Color Your Site! Let me familiarize you with the problem.

Especially people who suffer with myopia need to set system colors and webpages to colors which are not that bright. Because the bright colors make eyes burning or hurts. Especially fatigue and headache are related with this. Somebody has dark schemes on his OS, but this is not my case, I use #d9c195 for background and black for text (see attachment). Then I use addon to inject Black background css styles, but some webpages are better to view in system colors. Color Your Site! enables me to set particular site or domain do black background and very light yellow text. This saves my eyes greatly so I can spend hours reading websites. But often when I hit new site I have set the default colors to be used. Which is also good. 

But now collision here comes. When the default colors are on, I cannot see the injected colors. I must manually click at least 7 times to do the following:


Actual results:

There are these two options in Content settings:

"Use system colors": checked
"Override the colors specified by the page with my selections above": always

This applied default colors to sites. In my system I have set colors which does not make my eyes hurt (no white background).

To enable the css styles injection I need to switch it to:

"Use system colors": off
"Override the colors specified by the page with my selections above": never

It is 7 or 8 clicks total! Now imagine that you need to do it often. That is crazy!

I am sure I am not the only one who minds this. Especially users who have set black theme in their OS and want to apply it to webpage. But not all webpages looks good using default styles. Some looks good in black background some in system colors.

I am also developing webextension to improve access to these things. I would like to create such addon which will switch these two settings with a single click or with hotkey. But there is not API which could enable me to do it.


Expected results:

1) create an icon to toggle these settings
2) add a hotkey to the toggle command
3) create API with access to these two options which will enable to integrate the toggle action into the webextensions.
4) you can add access to another options in the Content options.
Component: Untriaged → Disability Access
Priority: -- → P1
Hardware: Unspecified → x86
5) add colors "window", "background" and similar system colors to Tools/Options/Content/Colors/... into the window of colors. This would enable to use selected color for specific item in specific cases ... but this would had a sense only if the background color option would be applied to empty tabs. Because currently they stay white even if I change this option.
Andy, can you remind me what's the status of adding (semi-)arbitrary builtin pref setting APIs to webextensions? Are we still considering doing this, or not, or...?
Flags: needinfo?(amckay)
Priority: P1 → --
We will be doing this, but focusing on a the high level API rather than being tied to the specific preference, so that we can change preferences without breaking the API.

Before we get into that, I think this might be something the themeing team have thought about, so I'm just going to ping jaws...
Flags: needinfo?(amckay) → needinfo?(jaws)
(In reply to Andy McKay [:andym] from comment #3)
> We will be doing this, but focusing on a the high level API rather than
> being tied to the specific preference, so that we can change preferences
> without breaking the API.

OK. I think this bug is effectively "wontfix" for including a button to toggle this particular pref in Firefox by default.

> Before we get into that, I think this might be something the themeing team
> have thought about, so I'm just going to ping jaws...

I don't think we want themes to change how websites are displayed (which is what this pref controls - it doesn't as a rule alter Firefox UI (though it might alter in-content UI)). I also don't really see how a theme toggling this pref would make things easier unless the theme can add arbitrary controls to toggle the pref, which I think goes back to having webextensions APIs to do that (if we want to support it at all). Leaving ni for jaws just in case.
(In reply to :Gijs Kruitbosch from comment #4)
> > Before we get into that, I think this might be something the themeing team
> > have thought about, so I'm just going to ping jaws...
> 
> I don't think we want themes to change how websites are displayed (which is
> what this pref controls - it doesn't as a rule alter Firefox UI (though it
> might alter in-content UI)). I also don't really see how a theme toggling
> this pref would make things easier unless the theme can add arbitrary
> controls to toggle the pref, which I think goes back to having webextensions
> APIs to do that (if we want to support it at all). Leaving ni for jaws just
> in case.

Ah sorry I misunderstood the bug.

Of note, bug 1310026 is about adding in a USER_SHEET which should override any page css. Would that help? If so, perhaps we just move this bug over to WebExtensions or dupe to bug 1310026.
Flags: needinfo?(bugzilla12345678)
(In reply to Andy McKay [:andym] from comment #5)
> Of note, bug 1310026 is about adding in a USER_SHEET which should override
> any page css. Would that help? If so, perhaps we just move this bug over to
> WebExtensions or dupe to bug 1310026.

If the extension can toggle the extra sheet being included (e.g. based on an internal pref hooked up to a button), then I believe it would, yes.
Component: Disability Access → WebExtensions: General
Flags: needinfo?(jaws)
Product: Firefox → Toolkit
See Also: → 1310026
Summary: Create icon to toggle system colors → Add an API to allow toggling 'use system colors' preference
Depends on: 1320736
To summarize ideas so far:

* Flipping prefs is something we want to do in WebExtensions, but we haven't done yet, so we could make this bug dependent upon a suitable pref flipping module (bug 1320736)

* This particular instance sounds great for a general "accessibility" API for Firefox that we should think about.
Priority: -- → P3
Whiteboard: triaged
Adding another one to the bucket of bug 1363856.
Blocks: 1363856
Just wondering about how bug 1310026 comes into play with this, if at all? This was discussed in comment #5 and comment #6.

Bug 1363856 is only about creating APIs that grant access to certain preferences, so is this solely about being able to change the values of "Use system colors" and "Override the colors specified by the page with my selections above"?

What are the various combinations of those preferences we want to support? Ideally this would be implemented as a single "setting" API, which would control both prefs behind the scenes. When an extension changes the value of this setting, both prefs would be changed, which is why we need a list of all the combinations that we want to support, along with a descriptive name for each of these combinations. I'm not sure who is best to provide me with that.

Andy and/or Gijs, can either of you address my questions?
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?(amckay)
(In reply to Bob Silverberg [:bsilverberg] from comment #9)
> Just wondering about how bug 1310026 comes into play with this, if at all?
> This was discussed in comment #5 and comment #6.

I don't know, exactly. I think it's probably possible to implement some of the desired functionality without anything more than user CSS per bug 1310026. I think there are still parts of it for which we would need this bug.

> Bug 1363856 is only about creating APIs that grant access to certain
> preferences, so is this solely about being able to change the values of "Use
> system colors" and "Override the colors specified by the page with my
> selections above"?
> 
> What are the various combinations of those preferences we want to support?
> Ideally this would be implemented as a single "setting" API, which would
> control both prefs behind the scenes. When an extension changes the value of
> this setting, both prefs would be changed, which is why we need a list of
> all the combinations that we want to support, along with a descriptive name
> for each of these combinations. I'm not sure who is best to provide me with
> that.
> 
> Andy and/or Gijs, can either of you address my questions?

There are 6 relevant prefs, I believe:

- whether we use system colors rather than user-selected colours ( browser.display.use_system_colors )
- whether we use the author (document) colours over user/system ones ( browser.display.document_color_use - this is tristate, always, high contrast mode only, never -- default is 'high contrast mode only')
- which colours to use for:
-- foreground - browser.display.foreground_color
-- background - browser.display.background_color
-- unvisited link - browser.anchor_color
-- visited link - browser.visited_color

The last 4 are obviously colours, not just toggles. I expect you'd want to use some kind of settings dictionary for that, or 4 separate ones. I'm not sure if we desperately need to provide add-on access to the system colors one. The other one, effectively about whether we use author/document colours at all, I guess we'd need to provide access to.

Does that help?
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to :Gijs from comment #10)
> (In reply to Bob Silverberg [:bsilverberg] from comment #9)
> > Just wondering about how bug 1310026 comes into play with this, if at all?
> > This was discussed in comment #5 and comment #6.
> 
> I don't know, exactly. I think it's probably possible to implement some of
> the desired functionality without anything more than user CSS per bug
> 1310026. I think there are still parts of it for which we would need this
> bug.
> 

Thanks for your responses, Gijs. At this point I'm still confused about whether we need to do anything regarding this bug, if it's possible the reporter's use case can be covered by bug 1310026. 

bugzilla12345678 (the original reporter), can you please check to see if what's already been implemented for bug 1310026 will help you solve this problem?

> > 
> > What are the various combinations of those preferences we want to support?
> > Ideally this would be implemented as a single "setting" API, which would
> > control both prefs behind the scenes. When an extension changes the value of
> > this setting, both prefs would be changed, which is why we need a list of
> > all the combinations that we want to support, along with a descriptive name
> > for each of these combinations. I'm not sure who is best to provide me with
> > that.
> > 
> 
> There are 6 relevant prefs, I believe:
> 
> - whether we use system colors rather than user-selected colours (
> browser.display.use_system_colors )
> - whether we use the author (document) colours over user/system ones (
> browser.display.document_color_use - this is tristate, always, high contrast
> mode only, never -- default is 'high contrast mode only')
> - which colours to use for:
> -- foreground - browser.display.foreground_color
> -- background - browser.display.background_color
> -- unvisited link - browser.anchor_color
> -- visited link - browser.visited_color
> 
> The last 4 are obviously colours, not just toggles. I expect you'd want to
> use some kind of settings dictionary for that, or 4 separate ones. I'm not
> sure if we desperately need to provide add-on access to the system colors
> one. The other one, effectively about whether we use author/document colours
> at all, I guess we'd need to provide access to.
> 
> Does that help?

Thanks Gijs, yes that clarifies things a bit, but I'm still not sure how to translate those combinations into a meaningful API. I think we need some use cases for this proposed API, and thus far all we have is the original report. Rob, as someone who has been advocating for new APIs for legacy add-ons, do you see a need for an API like this? Do you know of any use cases?
Flags: needinfo?(rob)
Flags: needinfo?(amckay)
User CSS already provides enough flexibility to customize colors, even more flexible than those preferences. Hence I don't think that it is necessary to expose the browser.*_color preferences through a WebExtension API.

There is one issue - WebExtensions cannot run in all pages, e.g. other add-on pages, privileged chrome pages, addons.mozilla.org. This is normally good because of security, but bad for add-ons that legitimately need such access for accessibility (e.g. text-to-speech add-ons).
Allowing arbitrary content scripts is difficult, but after validating a stylesheet and restricting it to a strict subset of CSS, it should be fine to allow insertion of a stylesheet in any page.
Flags: needinfo?(rob)
(In reply to Rob Wu [:robwu] from comment #12)
> User CSS already provides enough flexibility to customize colors, even more
> flexible than those preferences. Hence I don't think that it is necessary to
> expose the browser.*_color preferences through a WebExtension API.
> 
> There is one issue - WebExtensions cannot run in all pages, e.g. other
> add-on pages, privileged chrome pages, addons.mozilla.org. This is normally
> good because of security, but bad for add-ons that legitimately need such
> access for accessibility (e.g. text-to-speech add-ons).
> Allowing arbitrary content scripts is difficult, but after validating a
> stylesheet and restricting it to a strict subset of CSS, it should be fine
> to allow insertion of a stylesheet in any page.

Ok, so this is now sounding like a WONTFIX, as user CSS will do essentially the same job, except for a few special pages. Do you agree Rob?
Flags: needinfo?(rob)
SGTM. If someone sees my comment about allowing a safe subset of CSS on any page and believes that it is a good idea, then they can file a separate bug.
Status: UNCONFIRMED → RESOLVED
Closed: 7 years ago
Flags: needinfo?(rob)
Resolution: --- → WONTFIX
Flags: needinfo?(bugzilla12345678)
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: