Background color is always white, top banner is never displayed in Firefox

Related to Suite bug 19260?

>> Related to Suite bug 19260?

It appears so, but I'd hope it gets fixed in FF in addition to the suite.

There should be TWO checkboxes in the color setting preferences, NOT one. One should set whether to use your background and text colors. The second should set whether to use your link colors. This may be the checking to see if main reason that this is not working properly now. It is NOT doing what you say it will do in the Help file entry:
 "Colors Dialog:

Text and Background

        Here you can change the default text and background color to be used on
        web pages that haven't specified that information. Click on the color
        samples to select colors.

Use system colors

        Check this optionpreference to use the colors defined in your OS settings
        instead of the colors specified above.

Link Colors

      Here you can change the default colors for Web links. Click on the color
        samples to select colors.

Underline links

        By default, links are underlined on web pages. Uncheck this optionpreference
        to disable this. Note that many sites specify their own styling rules
        and this optionpreference has no effect on those sites.

Allow pages to choose their own colors, instead of my selections
        above

        By default, Firefox uses the colors specified by the web page
        author. Disabling this optionpreference will force all sites to use your
        default colors instead."

Please take Special NOTE of the last Paragraph of the Help file entry! Having only ONE checkbox makes it impossible for users to choose anything other than page default underlining without some type of work-around. This is especially annoying on pages where they make the visited links the same color as unvisited links, so please make it possible to select these two color customizations independently so that we can customize our links without killing site colors for backgrounds and text. This is the root of this bug!

*** Bug 347815 has been marked as a duplicate of this bug. ***

Some sites have navigation affected by this, presumably because they use funky CSS background images to get the result they want. If you have this setting turned on, you can't even see the navigation menu.

It's not enough to choose the colors for text and links, because they'll then probably conflict with the background. Indeed, it's not telling the whole truth if you don't say it overrides background images, too. Maybe a separate check box to override background images would be good?

For example, ArsTechnica.com (in the 'Emporium Shop.Ars Open Forum Subscribe' menu near the top of the page) and AListApart (the 'Hosted by' and 'Published By' menu on the right).

As i understand this has been fixed in Firefox as stated at https://bugs.edge.launchpad.net/firefox/+bug/27867

Is there a way for me to close this bug I cant seem to find a way to do it.

>As i understand this has been fixed in Firefox as stated at

No, prima facie not. The linked bug states it's 'fixed' because the option isn't there anymore, yet the option is there in the latest nightly so that's wrong.

>Nope. The Preferences dialogue has been reworked since, and the "offending"
>option isn't even present anymore, so it's now impossible to screw things up ;-)
>Bug fixed then...

Maybe you're confused because the option is now 'allow sites to...'?

ok will reopen LP bug than. thanks for the update.

This is rediculous. The embedded video player on FIREFOX's OWN site, that is supposed to show off the cool new video support in 3.5, doesn't work because of this bug. This bug has been a huge frustration for many people for a LONG time. It directly affects usability of MANY websites. This bug needs to be fixed!

485116 has been tagged as a duplicate of this. In any case, it is weird to see this problem still existing after four-plus years. What gives with this?

*** Bug 418913 has been marked as a duplicate of this bug. ***

*** Bug 565154 has been marked as a duplicate of this bug. ***

*** Bug 485116 has been marked as a duplicate of this bug. ***

*** Bug 441784 has been marked as a duplicate of this bug. ***

Kevin,

I hope all this activity relating to this, and similar bug reports, means that someone will be working on resolving the problems.

George...

From what i can see Ubuntu has fixed the problem
already, however i am using the nightly build and
can not reproduce this bug in Luci/Maverick using
version:
3.6.5~hg20100511r34172+nobinonly-0ubuntu1~umd1

On 05/12/2010 06:43 AM, Grgoffe wrote:
> Kevin,
>
> I hope all this activity relating to this, and similar bug reports,
> means that someone will be working on resolving the problems.
>
> George...
>

--
Sincerely Yours,
    John Vivirito

https://launchpad.net/~gnomefreak
https://wiki.ubuntu.com/JohnVivirito
Linux User# 414246

"How can i get lost, if i have no where to go"
    -- Metallica from Unforgiven III

John,

Ubuntu fixed the problem? Did they make a mod to FF or is their mod to the desktop manager?

I'm using KDE on a Fedora 16 x86_64 system AND the Nightly build. With my color settings enabled a lot of things don't work. Things like a submit button disappear.

George...

Why is this bug not even confirmed? I discovered this because I like to read light text on a dark background, so I set my own colors and now links and images disappear. For example, Google's logo from Google search results. Why are text colors affecting images anyway? If I could find a color inverting or high contrast add on to do this it would be nice, but can't find that for FF.
Thanks

I think that, as in many things, it is good to clarify the underlying facts.

The OS has little to do with this. However, the DE (Desktop Environment) can play havoc with the programs that run under it. Also, the programmers of the individual apps do have the ability to maintain their own little environment separate from the DE. I would think that it is best to let the user choose if she wants a given app to be controlled by the DE, or to remain controlled within its own space.

In this case, we see a problem of the mixture of app control overlapping with DE control. That is the worst of all worlds IMHO. I would guess that the GUI portion of the program is not coded correctly.

I'm not an (active) developer of FF, but I think this problem (bug) exists because when a user chooses under tools > options > content > font & colors to select her own colors it alters how the browser interprets CSS font colors and thereby CSS in general. Nothing to do with OS, DE or other settings.

My recommendation is:
Allow change of font and background color to change font and background color ONLY. Background images, sounds, etc can be separate check boxes or located somewhere else. (CSS options, maybe?)

-Joshua

I simple option box to deselect DE setting within the program should solve the problem if the program is properly coded. It must clearly offer the choice of one or the other.

Josh, et. al.,

This css problem is exacerbated by Yahoo's choices with their email web site. With "my" colors selected, the display is almost completely useless.

George...

*** Bug 418913 has been marked as a duplicate of this bug. ***

*** Bug 892265 has been marked as a duplicate of this bug. ***

"Status: NEW"? This bug looks to be 8 years old!

I would ask when this is going to be fixed but I'm not stupid: This bug will never be fixed.

Just another reason to despair about Firefox, eh?

Sorry, Mark, for the problems you find with the program. Please know that I share your dispair at the way things are.

As I've explained elsewhere before, there is little interest in the Mozilla community to polish the programs they create to make them as the users might wish them to be. The programmers are doing this for free, and they are doing it as they wish, which is their right. That's just the rub of it.

Sadly, too many people have come to depend upon the software on a daily basis. But that is the problem of the free software arrangement. Of course, even if one paid for it, the program creators might still not have the same vision, or care to serve the needs of the users. That's just life.

No need to complain, I guess. Just hang in there, Pal. I understand, and we are not alone.

*** Bug 728948 has been marked as a duplicate of this bug. ***

Will Australis address this?

No. This bug request is likely to require some advanced work on the Gecko engine. It essentially would require partial CSS parsing where only a few elements/attributes are whitelisted.

OK, I see. So we redesign the whole interface, alienate and probably lose thousands of users who have stuck with Fx because they don't like Chrome, but can't fix a fundamental basic flaw in the way the browser is supposed to work. Sounds good to me.

Sorry for the sarcasm, but - as Robert Plante sang - "and it makes me wonder ..."

Actually, the correct way to handle this problem is to select a team of programmers and a director to lead them. Then have them work on a parallel product to replace the existing program with a better, more streamlined version with properly modular, segmented and documented code that would be conducive to the addon process. Then when it is released, it would supercede the existing without scaring away any users or addon programmers.

It may not be as big a project as people might perceive. It just needs to reuse the good existing code, while bringing it up to twenty-first century standards.

Commenting on this bug since there is a lot of people saying “they should do X” or “this requires Y” with apparently no knowledge of what is happening.

Attention people:
THIS PROBABLY CANNOT BE FIXED, EVER.

What’s happening with this option (browser.display.use_document_colors=false) is that the browser ignores web page style (CSS) declarations for:

- text color
- background color
- border color
- background images

The problematic part here is background images. Let’s say a website uses a dark background image (it could be a photograph, a gradient, a repeated pattern, etc.), and declares `color: white` for the text. If we display the background image but ignore the white color, and the user’s default color for text is black, we end up with black text on a black background. The user can’t read. If we keep a light background image, but the user has set their default text color to white or something similarly bright, we end up with light text on a light background and poor or no readability.

So Firefox disables background images because there is no other obvious way to make sure that text can be read if it keeps background images.

Now, what happens on many sites is that web designers and developers have used background images to represent actual content, rather than decorative backgrounds. Especially (but not exclusively) with one questionable and inaccessible webdesign technique called CSS Sprites. Some sites use background images to represent the content of most navigation items and buttons. This is a misuse of the HTML and CSS standards, but it’s still a fairly common (bad) practice. When background images are disabled, those navigation items and buttons just disappear (thought technically they’re still here and can be clicked—they’re just transparent).

Keeping background images is not a solution since it would result in unreadable text, that would nullify the purpose of the “Always use my colors” option.

Possible solutions are:

1. Make every website that uses background images for content change their site. Sadly there will always be websites that do not follow accessibility best practices.

2. Build a brand new solution for a custom color and/or high contrast mode, that analyzes background images and tries to determine programmatically if they should be discarded or kept around.

I don’t see Mozilla committing weeks of developer time to design, build, test and ship a new high contrast mode that can deal fairly well with CSS Sprites and backgrounds-that-shouldn’t-be-backgrounds, unless there’s a strong demand for it. Of course anyone with strong CSS and (for instance) JavaScript knowledge is welcome to try something like this and build a proof-of-concept.

Hi,

It seems to me that you're trying to keep the user(s) from doing something stupid.

Users will almost ALWAYS try to do something stupid, not necessarily on purpose but by accident. Like black text on a black background. It's inescapable. Don't even try. Perhaps a disclaimer when the option to use user settings instead of a sites settings would be enough? It would CERTAINLY be for me. Maybe, you can add a button or something in a predictable part of the display that would let the user change the settings back to defaults for a specific site. Maybe two consecutive "clicks" would switch away and then switch back? Maybe forever? Maybe for just this one instance where the browser is displaying a particular site?

I would find such a solution quite acceptable.

Thanks for your masterful, well thought out response for this bug.

George...

George: my point was not about users selecting black text and black background. My point was that the only way to respect the user’s choice of colors is disabling background images altogether.

And disabling background images will make some elements disappear because they have been coded as background images when they shouldn’t have been. (And it’s a bad practice that is, alas, VERY common in web pages — see Bug 1008583 for an example of this bad practice in Firefox itself.)

Let me explain how text and backgrounds are painted over a page or an area of a page. They are painted in three layers, from the top to the bottom:

1. Text and content images
2. Background image
3. Background color

If they are present, background images (which can be repeated as a pattern and cover a full page or area of a page) will be painted on top of the background color, hiding that background color.

Let's say a user defines their preferred color as text=black, background=white. Pretty straightforward.
Now let’s say a website defines colors like this for the main content of their pages:

1. Text = #A0A0A0 (a light gray)
2. Black or dark background image (e.g. http://subtlepatterns.com/txture/)
3. Background color = #101010 (almost black)

If we change the text and background color to the user’s preference, BUT keep the background image, we end up with:

1. Text = black
2. Black or dark background image
3. Background color = white

So we end up showing black text on a blackish background (the background image, which completely covers the background color). The white background color is not visible, and the text can’t be read.

Of course if the user chooses white text (and a black or dark background) it works in this case, but it will break on many other sites. Background images uses for decorative patterns, gradients and other effects are very common on the Web (though a bit less popular in webdesign in the past 2 years).

So Firefox has to disable background images for this feature (“Use my own colors”) to work. BUT bad web developers use background images when they shouldn’t (because in some cases it’s easier to do, and it even has some benefits for making websites speedier). So disabling background images makes some websites hard to use (e.g. disappearing buttons).

This can’t be fixed with a simple tweak of this feature. And it might not be possible to find a more elaborate solution (read: days or even weeks of developer time) that yields good results.

Created attachment 8420698
unreadable-text-when-keeping-bg-images.png

Visualisation of the example in Comment 35.

Florent,

Thank you for all your precious time spent in clarifying this situation. It really is a bag of worms. Unfortunately.

Does anyone know of a browser that does this better? Maybe what they do could be applied to this situation?

This is like trying to make everyone happy. Virtually impossible to do.

I had written a bug about changing font sizes affecting the display of text adversely... resulting in buttons that are only half (or less) there. Probably the same situation as this one. Sigh...

Again, thanks for your explanation.

George...

If the problem is from outside FF, then I do not believe it is an issue of pleasing everyone. We should never try to appease those who use non-standard ways of doing things. If any people do not conform to W3C standards, they are actually part of the problem.

We can try to educate, but the software must conform. The more that all browsers conform, the less we will have weirdo behavior from those like IE.

With that said, the best way is always to re-write code to do what was requested in the first post. However, if the text is actually an image, then an error message that simply states that fact will go a long way to user understanding of the problem others create. No text to adjust will give no adjustment. That's just the way it is. Besides, that is reasonable.

Bottom line, FF should give feedback by way of explanation.

*** Bug 1256663 has been marked as a duplicate of this bug. ***

*** Bug 1265265 has been marked as a duplicate of this bug. ***

*** Bug 1497756 has been marked as a duplicate of this bug. ***

*** Bug 1549613 has been marked as a duplicate of this bug. ***

you can find the data related to this @ https://www.marketingbusinessweb.com/digital-technology-of-the-future

@johnwelster
www.marketingbusinessweb.com

The skin absorbs approximately 60% of whatever implemented to it. However, the pores and skin is a protective barrier that prevents dangerous compounds from getting into the frame. Interestingly, topical non-public care products can reach frame systems, inflicting untold health outcomes.
Read More:- https://www.gethealthandbeauty.com/

Cloud verbal exchange is now not a telephone line clients use to reach you, thanks to the latest updates and advancements. As a result, it's far now a essential aspect of emblem constructing that can quick install the necessary resources and manipulate the entire brand conversation device.
Read More:- https://www.primewebreviews.com/

You can find the option here: https://bugs.edge.launchpad.net/firefox/+bug/27867

Thanks

george grace
https://www.workebook.com/

I am Ameliaroy , working for techandbusinessnews as PR consultant. With more than 6 years experience in PR and Digital Industry, helping teams to achieve goals by streamilining the process. https://www.techandbusinessnews.com/

Redirect a needinfo that is pending on an inactive user to the triage owner.
:jaws, since the bug has recent activity, could you have a look please?

For more information, please visit [auto_nag documentation](https://wiki.mozilla.org/Release_Management/autonag#inactive_ni_pending.py).