Open Bug 1450832 Opened 6 years ago Updated 11 months ago

Text or background colors remain on custom setting even when i click "display" never

Categories

(Firefox :: Settings UI, defect, P3)

59 Branch
defect

Tracking

()

Tracking Status
firefox-esr52 --- wontfix
firefox-esr60 --- wontfix
firefox59 --- wontfix
firefox60 --- wontfix
firefox61 --- fix-optional

People

(Reporter: andres.rosales, Unassigned)

References

Details

(Keywords: regression)

Attachments

(3 files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180323154952

Steps to reproduce:

--I manually changed text and background color, and set it to display always.

-- then noticed that certain objects or texts would disappear by being changed into the background color. and i could only see it by highlighting it. also search bars were difficult to see. 

--so i changed display 'always' to 'never' however on some webpages, sometimes it'll be text,sometimes background, will be the color i had manually changed them to. 


Actual results:

Colors are sometimes displaying in an undesired way, both with a custom set-up and when you disable that set-up.


Expected results:

Colors should be returned to default setting when i click display 'never'.
(In reply to Blur Blanc from comment #0)

> --I manually changed text and background color, and set it to display always.
Could you please provide actual steps on how you did this? 

> -- then noticed that certain objects or texts would disappear by being
> changed into the background color. and i could only see it by highlighting
> it. also search bars were difficult to see. 
A screenshot displaying the actual issue would be greatly appreciated.

> --so i changed display 'always' to 'never' however on some webpages,
> sometimes it'll be text,sometimes background, will be the color i had
> manually changed them to. 
Would you please also provide where did you change this from and how?
Flags: needinfo?(andres.rosales)
Flags: needinfo?(andres.rosales)
Thank you for the reply!

I managed to reproduce the issue on Windows 10 and Mac OS X, Nightly 61.0a1 (2018-04-18), Firefox 60 and Firefox 59.

Marking the bug as New on Preferences component.
Status: UNCONFIRMED → NEW
Component: Untriaged → Preferences
Ever confirmed: true
OS: Unspecified → All
Hardware: Unspecified → All
Gijs, I think this was broken ever since bug 639134 landed. I can reproduce it by setting the text color to bright yellow, changing the dropdown to "Never", and visiting data:text/html,<p>this is a test</p>
Blocks: 639134
Flags: needinfo?(gijskruitbosch+bugs)
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #6)
> Gijs, I think this was broken ever since bug 639134 landed. I can reproduce
> it by setting the text color to bright yellow, changing the dropdown to
> "Never", and visiting data:text/html,<p>this is a test</p>

I don't really understand. If you pick yellow text and have the default (ie white) background, then those are the colours we will use unless the website's CSS instructs us otherwise. In this case, there is no website CSS. So we use the default colours. So this is working as designed. The text in front of the dropdown where we're selecting "Never" doesn't say "Do you want us to ever use these colors", it says "Override the colors specified by the page with your selections above" - which is exactly what it's doing. If I visit the testcase you cited and use the devtools to add a stylesheet, and add `p { color: black }` then that overrides the defaults specified in the preferences as expected.

This worked the same way prior to bug 639134 - if I load the same testcase and have changed the colours the same way, and leave "Allow pages to choose their own colours, instead of my selections above." ticked, text shows up yellow. (Ditto, of course, if I do untick that box.)


So as filed, I think this bug is invalid. I don't think setting the override functionality to 'never' should change the defaults back to what they are by default. If it did, then the colorpickers should all be greyed out in that case and we should only visually change the colorpickers without touching the pref (so that if you accidentally select 'never' and then go back, we put back your customized colors). But this would require some significant changes to layout in that it would mean users could never configure default colours without overriding website colours. It's also not clear how that'd work with the "use system colours" checkbox.

Generally, the colour preferences are pretty messy. I tend to think that the current colour selection doesn't provide enough options, provides some options that are unnecessary/redundant, and that it's too easy to end up in situations where either the foreground or background colour doesn't get overridden correctly (because the webpage hasn't set it), and on the other hand we don't offer users necessary control. We also aggressively remove various types of styled images, which sometimes make webpages hard to use. See e.g. bug 1266172 (and related) and bug 1430969 for some semi-recent examples.

So I wouldn't be opposed to rethinking this from a high level, but as-is I don't think there's much we can do here without that larger project, and I don't think we will be embarking on that larger project any time soon. Even if/when we do, I think the main plan would have to be decided by the a11y and layout teams - we would just build the required preference interface. So I think we should close this. Jared, thoughts?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(jaws)
I think there is a legitimate bug here, such that the wording for this dialog can be confusing and "Never" may imply to users that these colors will _never_ be used. It seems the fix for this is to change the text to be less ambiguous.
Flags: needinfo?(jaws) → needinfo?(gijskruitbosch+bugs)
(In reply to Jared Wein [:jaws] (please needinfo? me) from comment #8)
> I think there is a legitimate bug here, such that the wording for this
> dialog can be confusing and "Never" may imply to users that these colors
> will _never_ be used. It seems the fix for this is to change the text to be
> less ambiguous.

We can add a verb ("Never override"), maybe? Would that help?

... though then it'll be "Only override in High Contrast themes", which will be even longer than it already is in German. :-\

(Semi-related bug: the dropdown takes the size of the selected entry which means some/all the other items get clipped if you select "Never" or "Always". I wonder if that's a new bug...)
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(jaws)
(In reply to :Gijs (he/him) from comment #9)
> (In reply to Jared Wein [:jaws] (please needinfo? me) from comment #8)
> > I think there is a legitimate bug here, such that the wording for this
> > dialog can be confusing and "Never" may imply to users that these colors
> > will _never_ be used. It seems the fix for this is to change the text to be
> > less ambiguous.
> 
> We can add a verb ("Never override"), maybe? Would that help?

Maybe "Use as default" would make more sense?

> (Semi-related bug: the dropdown takes the size of the selected entry which
> means some/all the other items get clipped if you select "Never" or
> "Always". I wonder if that's a new bug...)

I used mozregression to find that this was broken by https://hg.mozilla.org/mozilla-central/rev/28bddcbef8e1#l1.92
Flags: needinfo?(jaws)
Flags: needinfo?(gijskruitbosch+bugs)
:mheubusch, would it be possible for you to chime in?

Right now we have some UI that looks like this:

----
{color picking options}

Override the colors specified by the page with your selections above
[dropdown list with options:
 [Always]
 [Only with High Contrast themes]
 [Never]
]
----

You can see this yourself by going to Options/Preferences, searching for "color", and clicking the [Colors...] button that shows up.


The problem is this: the top colorpicker buttons all allow you to configure *default* colors.
However, *most* but not *all* websites will include style information that tells the browser what colour the text and/or background should be. So changing the default will change a few websites completely, most websites only a bit (sometimes in ways that renders text unreadable because of the background/foreground combination) and some websites not at all (if the websites are very specific about the colours they want to use).

Now, the bottom dropdown is meant to (sort of) deal with this. It allows the user to specify whether the default colors they pick should take precedence over whatever a website says. So if you select "Always", the selection of colours will override the ones from the website. If you select "Never", then the option works as I described earlier - we change the defaults, but websites that specify styling (nearly all websites) will override those defaults.
The middle option (Only with High Contrast themes) is the same as "Never" in almost all cases, *except* if the user is on Windows and is using a High Contrast theme in the operating system. This is primarily used by people who e.g. are colorblind or have other issues with the default colourschemes applications use. If the user is using such a theme, Firefox behaves as if "Always" was selected (so it will override website colours). This middle option is also the default option in this list (this is so that if a user uses such a theme, Firefox tries to render webpages using the same colours as those used in other Windows application, to help with whatever vision issues the user might have).


It seems some users are confused by this combination of controls. They expect "Never" to effectively "turn off" their alternative selection of default colours. Could you suggest better phrasing for the label and/or options of the dropdown control to clarify what it's supposed to do (ie control whether websites still get some measure of control over the colours used to render them, or not)?
Flags: needinfo?(gijskruitbosch+bugs) → needinfo?(mheubusch)
This bug sounds legit, but currently not earth shattering. Marking P3.
Priority: -- → P3
Severity: normal → S3

Clear a needinfo that is pending on an inactive user.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.

Flags: needinfo?(mheubusch)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: