Open Bug 738948 Opened 12 years ago Updated 2 years ago

Provide Option with UI for Using User's Specified Background Color for Stand-Alone Images


(Core :: Layout, enhancement)






(Reporter: david, Unassigned)



(Keywords: access)

Implementation of bug #376997 forces black to be the background color when an image is viewed alone (e.g., right-click and select View Image on the pull-down context menu).  This overrides any user-specified background color.  When a user specifies a background color other than the default white (#FFFFFF), the user obviously wants that color to be used as the background in the browser window.  

Thus, this RFE requests an option -- with a UI -- to use the user's requested background color.  Currently, the extension Old Default Image Style provides a work-around.  That extension, however, should be considered only a temporary work-around for this RFE.  

See bug #717226 and bug #376997 itself for further discussion of dissatisfaction with the implementation of the latter bug.
Already denied at bug 713230 comment 34.
I don't intentionally mark this as DUPLICATE to clarify the purpose of bug 713230. Feel free to dupe if you disagree.
Blocks: 376997
Closed: 12 years ago
Resolution: --- → WONTFIX
Note that many discussions in the comp.infosystems.www.authoring.html newsgroup emphasize NOT overriding user settings in browsers.  The FAQ for that newsgroup is cited in Mozilla's own <>.  Here, you are overriding user settings, about which a number of users are complaining.  Thus, before closing this as WontFix, please explain why giving users an option is wrong.
Resolution: WONTFIX → ---
> The FAQ for that newsgroup is cited in Mozilla's own <>.
The document should be updated.
> Thus, before closing this as WontFix, please explain why giving users an option is wrong.
I already asked the reason in bug 376997 comment 87. Bug 713230 comment 34 also explains. I know you don't satisfy those answers, but it already answered.
Closed: 12 years ago12 years ago
Resolution: --- → WONTFIX
Despite being marked as WontFix, this RFE continues to attract attention and support.  The problem is that the citations in comment #3 DO NOT explain how implementing bug #376997 benefits the end-user or why implementing this RFE or bug #717226 would be a detriment to the end-user.  

This is beginning to remind me of bug #178506, for which an option was actually developed -- and then rejected -- to allow users to preserve the original time-stamp on a downloaded file, consistent with other file operations.  

While an extension to provide the capability requested in bug #178506 has over 1,100 users after a year, the extension to negate bug #376997 has over 5,200 users after only three months, which indicates this RFE indeed has some end-user support.  

Once again, I am reopening this RFE and request that an explanation be commented HERE (not by reference to some other bug report) why implementing this option would harmful to end-users before rejecting it again.  Note that bug #733954 (a replacement RFE for bug #178506) has been allowed to remain Open (so far) despite a WontFix on its predecessor.  Why not leave this Open for a serious evaluation?
Resolution: WONTFIX → ---
The reasoning is pretty simple - the vast majority of our users do not care to tweak the background color for standalone images, so it doesn't make sense for us to spend time developing preferences UI for that (making the preferences UI more complex in the process). There are various ways that the minority that does have strong feelings about standalone image background colors can customize the Firefox behavior (see , , etc.).
Closed: 12 years ago12 years ago
OS: Windows XP → All
Hardware: x86 → All
Resolution: --- → WONTFIX
There seems to be a major misunderstanding here.  I am NOT asking for an option for a user-set background color specifically for stand-alone images.  I am asking for an option that the existing user-set background color -- specified by the preference variable browser.display.background_color -- be used, as it was before the implementation of bug #376997.  

Try removing the general background color functionality of  browser.display.background_color and see how many complaints are made.  I believe that far more than a small minority of users do indeed choose to set this.
Resolution: WONTFIX → ---
(In reply to Gavin Sharp from comment #5)

Well, notwithstanding the efforts spent by that contributor to come with a solution, basing the override on which file type the URL ends is a bit of a hack. Bug 376997 hard-wired the style to a background color of #222, thus not even using any desktop-theme color that might fit. Images with transparencies to be shown in bright background almost disappear now (which, of course, would apply to other choices of color as well, but the previous white was to that extent neutral).

As a minimum, some kind of class or identifier should be provided to the definition in TopLevelImageDocument.css so that they can be overridden in a userContent.css more easily, rather than having to guess matching URLs.
Maybe the solution I posted on the 376997 bug page could help you.
Hi Dieter, thanks for pointing me to your bug 376997 comment #161. I'm actually applying a couple of custom patches to Mozilla release versions myself with each update and have it sufficiently scripted. While that's fine for you and me, it's not a general solution for everybody, thus a more user-friendly way to modify the image style (and videos, while we are there) would certainly be appreciated.
As you already mentioned "userContent.css" (and class or identifier in the mediaFile-template) should be the way to use. (If they have a reserved range of class names already it would be a matter of 5 seconds to add it, plus testing time, ok :P ). Of course it would be better to put the template data in a seperate resource file. And to finally change the concept of using an compressed folder (currently omnia.ja): they should just use a normal folder.

Is it a secret long time plan of the company, is it some personal feeling of some staff, or just that they don't want to admit they made a wrong decision in the architecture?

1. It seems to me, that some data is hardcoded in the code, in the current case the data used to create the structure of the mediapages; that page that then is used to display those single images or single videos. I don't know why they hardcoded it; and I'm only an enduser, so I really have no time to read through all that is available about the decision to put data hardcoded in the Firefox-file - but by doing this they get the usual problems now.

2. The reaction of the mozilla-staff here is just - mmh - let's call it unexpected.

3. I'm really bothered by the gray background, by the centering, by not being able to select it the old way with the mouse - I even registered here.

4. I don't like the suggested userstyles-addon (in general and) in this specific case, as I didn't find a way to first look into the actual code that should be apllicated. I don't have the addon installed now, and without the addon the userstyles-website doesn't even let me see the actual specific code for the image-fix.  

As enduser I'm in the lucky situation that I can turn Firefox's automatic updates off, so if I update manually and the image-display changes back, I know hot to fix it again.

Cheers up! :P
Back in Firefox 1.5, I used userContent.css to change the white background of blank.html to a quite light blue. Because when I opened a new tab the former white really was too bright on a big monitor.

I can't find the old userContent.css I used, but just a fast search finds for example:
@namespace url(;
@-moz-document url("about:blank") {
* {background-color: #000000;}

That would be a nice solution if it could be used for the image-pages.
That's basically what the stylish code does, just with the difference that the URL which needs to be matched is anything but a constant, thus requiring a non-trivial regexp which doesn't even cover all possible cases. So again, userContent.css overrides may be fine though hard to discover and apply for non-experienced users, but even for this id or class names need to be defined so that an unambiguous CSS selector can be specified for the elements in question.

Re omni.ja[r], that was changed a while ago from distinct *.jar files for reasons of performance penalties when having to read multiple files at startup.
Note that bug 713487 and bug 740668 made further changes to TopLevelImageDocument.css and TopLevelVideoDocument.css (effective with 14.0), while retaining the basic issue of not being able to select and override those hard-coded definitions with reasonable effort. Colors and the "noise" background pattern moved into the Toolkit theme though, thus may be potentially modified by 3rd-party themes now.
Per, the extension Old Default Image Style to override bug #376997 now has 12,321 users.  It also has 70 mostly favorable reviews; the least favorable review was a complaint about the extension not being updated.  I believe this proves that end-users want this RFE implemented.  

As for a use-case, consider an image that contains significant amounts of dark gray in and near its edges.  If that dark gray is the same as used by the implementation of bug #376997, the user cannot tell where the edges of the image occur.  

Furthermore, for some color-blind individuals, the image does not even need to contain actual dark gray at the edges.  Other colors that such individuals cannot distinguish because of their visual handicap might also make the edges of the image indistinct.  This could be a violation of the Americans with Disabilities Act (ADA).
Keywords: access
Product: Core → Core Graveyard
With the change from .xpi to Webextensions, the existing Old Default Image Style extension is no longer a valid workaround.  Per my comment #15, this is an accessibility issue under the U.S. ADA.  Thus, it should be fixed instead of shoved under the "graveyard" rug.
Component: Layout: Images → Layout
Product: Core Graveyard → Core
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.