Bad Firefox integration with dark themes

[Luca Livraghi]

I'm using Mozilla Firefox 3 Beta 5 on Ubuntu 8.04 with a dark theme. Now I see all the input boxes and buttons filled with grey colour. This happened even with Firefox 2, but I solved that problem with a quick guide under the comment "firefox fix" by Proton at the bottom of this page: http://www.gnome-look.org/content/show.php/Grey+Neu?content=60824

In Firefox 3 I can't correct this problem.

[Zach-zachlipton (zach-zachlipton)]

Chaning the qa contact on these bugs to me. MPT will be moving to the
owner of this component shortly. I would like to thank him for all his hard
work as he moves roles in mozilla.org...Yada, Yada, Yada...

[Asa (asa)]

updating to new owner. sorry for the spam.

[Q-daemonc-netscape-net (q-daemonc-netscape-net)]

Using build 2001030812, text in menus is now white, text in boxes is still black
on black background. Also this bug may be related to bug 67448.

[L. David Baron (dbaron)]

What's the name of the GTK theme you use where you see the problems?

[Q-daemonc-netscape-net (q-daemonc-netscape-net)]

Any theme with a dark background and white text will do.

[Q-daemonc-netscape-net (q-daemonc-netscape-net)]

Well, I'm trying to attach it, but bugzilla keeps timing out. The theme I'm
using is called Darkalloy. Some you might find on themes.org are Absolute-E,
Darkmarble,

[L. David Baron (dbaron)]

I've experimented a little with what we could do to fix this. If I change the
two places where we used the |text| color (WindowText and an equivalent non-CSS
color type) to use the |fg| color, then Darkmarble improves significantly, but
it huts some other themes including LCARS (a dark theme where the default text
|fg| color is the same as the default button background) and Metal (where the
default text |fg| color is not really intended to be used for significant chunks
of text. (That's generally the problem, I think -- that the |fg| color is made
to be used for bits of UI, but not the large chunks of text that it's used for
in "Use System Colors".)

I think part of the problem is coming from our system color use conventions:
 * there are places where -moz-field is used as a background, and it doesn't
have a matching foreground color
 * there are places where text that is not ButtonText colored is used on a
ThreeDFace background. (In the Windows system colors, ThreeDFace was defined
to be equivalent to ButtonFace -- the ThreeD* colors were added in Windows 95
when buttons went from a single-border raised appearance to a double-border
raised appearance. Is it a bug that we use the ThreeDFace color as a
background on things other than buttons?)

[L. David Baron (dbaron)]

The following patch is arguably correct, and it improves the situation in the
DarkMarble theme, but makes it worse in Metal (because it's using a color that
was intended for labels rather than large chunks of text) and LCARS (because we
use WindowText on a ThreeDFace background).

I think if we really want to fix this we need to change some of the ways system
colors are used in the Classic skin. To do this, it would be helpful to
understand exactly what some of the system colors (e.g., WindowText,
AppWorkSpace, etc) mean in Windows (since that's where they came from, and the
CSS definitions aren't too informative).

Index: nsLookAndFeel.cpp
===================================================================
RCS file: /cvsroot/mozilla/widget/src/gtk/nsLookAndFeel.cpp,v
retrieving revision 1.49
diff -u -d -r1.49 nsLookAndFeel.cpp
--- nsLookAndFeel.cpp 2001/03/10 03:17:07 1.49
+++ nsLookAndFeel.cpp 2001/03/10 04:08:04
@@ -224,7 +226,7 @@
     break;

   case eColor_windowtext:
- aColor = GDK_COLOR_TO_NS_RGB(mStyle->text[GTK_STATE_NORMAL]);
+ aColor = GDK_COLOR_TO_NS_RGB(mStyle->fg[GTK_STATE_NORMAL]);
     break;

   // from the CSS3 working draft (not yet finalized)

[Q-daemonc-netscape-net (q-daemonc-netscape-net)]

Just so everyone knows, text boxes are still completely unreadable in many GTK
themes, and 8.1 will be out in a few days.

[L. David Baron (dbaron)]

Should I back out all my changes for bug 67448? The above patch would be
part of such a backout, and wouldn't be such a problem with LCARS if we're
not getting real button colors. Or maybe I should just check that in and
fix many themes at the expense of LCARS and any other themes where the
button colors don't match the window colors?

[Q-daemonc-netscape-net (q-daemonc-netscape-net)]

Well, the only places I see a problem right now is the text boxes and text
lables in the personal toolbar. If these can be reverted to the way it was
before with your one-line patch, I say go for it. If it messes colors up in
other themes, then perhaps it's better to back the whole thing out until we can
do it a way that is "right" for all cases.

[Matthew Paul Thomas (mpt)]

--> Themes. Coming up with a -moz-CSS set of sane and cross-platform UI colors
is an idea which seems more attractive by the minute.

[P-ch (p-ch)]

isn't that fixed? at least, with FB gtk2 it is.

[Pde-cs (pde-cs)]

I'm still suffering from this bug on sites which use CSS to set the foreground colour in buttons and text entry widgets, but continue to inherit my gtk background colour. See, eg webmail.unimelb.edu.au (though I've asked them to add a background colour to their style sheets; I'll post the next example I come across). The gtk theme is at http://www.cs.mu.oz.au/~pde/greenstone++.tgz

What I'd really like to know: is there a way to make mozilla completely ignore the gtk theme? It's a bit silly to just take the buttons and text entry box colours out of context anyway.

[Rui Matos (tiagomatos)]

Created attachment 293394
Downloads info is unreadable

This bug still exists. Attaching 2 examples. These were taken with:

Build identifier: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.9b2) Gecko/2007121016 Firefox/3.0b2

on Fedora 8 with jimmac's Darkilouche gtk theme.

[Rui Matos (tiagomatos)]

Created attachment 293395
URL dropdown with almos unreadable text

See above.

[Rui Matos (tiagomatos)]

What's this bug status regarding the Firefox 3 release?

[Twentyafterfour+bz (twentyafterfour+bz)]

Is this really that difficult to fix? I'd be willing to work on a patch if there is a chance to get this into Firefox 3

[glen (webplate)]

Created attachment 312077
The awesomebar with the darkilouche theme...

The green urls are almost unreadable...

[glen (webplate)]

Created attachment 312080
The website identification box with the darkilouche theme.

Another situation where using a dark theme (GTK darkilouche) leads to unreadable text.

[Luca Livraghi (luca91)]

I'm using Mozilla Firefox 3 Beta 5 on Ubuntu 8.04 with a dark theme. Now I see all the input boxes and buttons filled with grey colour.

You can see it: 1)http://img138.imageshack.us/img138/5097/schermatarr2.jpg
                         2)http://img138.imageshack.us/img138/2788/schermata1iw4.jpg

This happened even with Firefox 2, but I solved that problem with a quick guide under the comment "firefox fix" by Proton at the bottom of this page: http://www.gnome-look.org/content/show.php/Grey+Neu?content=60824

In Firefox 3 I can't correct this problem.

[Alexander Sack (asac)]

can you please upload those images to launchpad as attachment to this bug?

[Christophe Olinger (olingerc)]

Hmm, I also use a dark theme, but do not have this problem.

Here an attachment of my firefox and of my system colors settings.

[Luca Livraghi (luca91)]

Interesting, so you have buttons and input boxes filled with dark colours too. But you have the white letters in the boxes, I have grey buttons and black letters.

[Lutz (webmaster-phatsonic)]

> I have grey buttons and black letters.

You think that's bad? I have black letters on black background for some sites and white on white for others... ;)

First things first:
- Hardy
- Compiz and Emerald
- Themes: "aud-Default" (Metacity) and "Enduro Black" (Emerald)
- Firefox 3.0b5 (Mozilla/5.0 (X11; U; Linux i686; de; rv:1.9b5) Gecko/2008041514 Firefox/3.0b5 ID:2008041514)

I tried to just overwrite the themes colors in firefox, but it didn't work, although it should.
I made a file "~/.mozilla/firefox/MY_PROFILE_FOLDER/chrome/userContent.css" with this content:

input, textarea, checkbox, select, option {
 background:#FFFFFF none no-repeat;
 background-image:none;
 background-color: #FFFFFF;
 color: #000000;
}
button, input[type=button], input[type=submit], input[type=reset], input[type=file] {
 background:#FFFFFF none no-repeat;
 background-image:none;
 background-color: grey;
 color: #000000;
}

Firebug showed me that the styles where used, but the input fields where still black on black.
BAD bug. The OS theme has to respect the firefox settings!

Next try:
Using the Web Developer Toolbar function "Add User Stylesheet". And here it gets strange: That worked perfectly!
The forms were usable and colored like I specified in the css file.

So it definitly seems to be a firefox-related bug. It's either a bug in FF3b5 or the Ubuntu integration fucked up somewhere along the road.

My short term solution: Having the css ready and use Web Developer Toolbar to repair non-working forms (like this one btw).
(And telling as many webdesigners as possible to fucking specify the colors they want on their sites. I really thought most people knew that by now.)

But that has to change pretty fast:
- Tools like Firebug (which I NEED for my job) don't really work in Beta5. (I made it "kinda" work, but it's next to impossible to use in the current state)
- Reinstalling FF2 didn't work on Hardy (couldn't find out why yet)
- And my Theme (which I can't change to a bright one without editing the configs for many apps that I changed to be white-on-black compatible) screws up many websites

I think I'm going on a vacation for a few weeks... ;)

[Lutz (webmaster-phatsonic)]

Just a quick follow-up:

I reinstalled FF2 on Hardy - everything else stayed the same.

Here the fix I mentioned above (css file in "~/.mozilla/firefox/MY_PROFILE_FOLDER/chrome/userContent.css") works.
So the bug only appears in the FF3 beta.

[Jose Hevia (jose-francisco-hevia)]

I have a real problem here, if you want to reproduce this bug:

Download a dark theme:
http://www.kde-look.org/content/show.php/Neutronium+DeepBlack?content=56429

http://www.gnome-look.org/content/show.php/Kore-Gnome?content=55747

http://www.gnome-look.org/content/show.php/Murrina-Black?content=46287

http://www.gnome-look.org/content/show.php/Smoked+Glass+v0.9.5?content=27141

FF3 Beta tries to use the colors but text boxes foreground is not changed while background is. Attached is a screenshot of my current screen.

[Jose Hevia (jose-francisco-hevia)]

Another screenshot.

[Luca Livraghi (luca91)]

That's it, this is the bug.
All you can do, it's click to System->Preferences->Themes->Customize and under the tab "colours", click on the left "input boxes" button and use this colour: #4A4A4A. You have the same problem, but with this trick the input boxes are clearer. In the other hand, we have to wait a fix of this bug (if there will be one).

[John Vivirito (gnomefreak)]

Alexander are you able to confirm this issue? I am unable to after trying the themes it works ok here, As i recall Firefox-3 was handling themes differently right that is why we no longer have theme package for 3.0? I will leave confirmed on that request for info.

[Alexander Sack (asac)]

Joe appears to be "gone"... flipping assignment to default again.

[Alexander Sack (asac)]

not sure if its still the same bug, but linking ubuntu bug https://launchpad.net/bugs/220263 ("Bad Firefox integration with dark themes") to this one.

[Alexander Sack (asac)]

OK, I set the proper upstream bug. Its rather old, but since it hasnt been really active we can probably high-jack it. Please continue discussion there.

[Phiw (phiw)]

Created attachment 323840
test case

STR
(these assume default theme at both browser and OS level - black text, white background).

1. load testcase
2. open Preferences > Content > Colors
3. adjust your colours: set dark/black background, light/white 'text' colour.
4. uncheck the 'Allow pages to choose their own colors...'

Actual result: watch the second row of form controls: the text in the form controls doesn't change colour (remains the default OS 'Text' colour)
Expected result: the text-colour in the styled form controls changes to the one specified in step 3 above.

Regression from FX 2. I suspect this regressed from bug 58048, but I haven't checked this yet

(Via the forums: http://forums.mozillazine.org/viewtopic.php?p=3398626#3398626)

[Phiw (phiw)]

Created attachment 323841
screenshot

What I see on OS X - default settings, with the colour/background changes as indicated.

That is with
Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a1pre) Gecko/2008060417 Minefield/3.1a1pre

Camino trunk builds and WinXP FX 3 RC2 show the same

[Kliu (kliu)]

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

[Kliu (kliu)]

A bit of searching turned up bug 419140 and bug 405207. Those were about changing the system color scheme, while this is about changing the browser color scheme, but the underlying problem may be the same...

[L. David Baron (dbaron)]

It sounds like you're saying that you want bug 58048 to be reverted, although it's not completely clear. If so, I think this should be wontfix.

[user2037 (user2037)]

I opened 437392 because styled form elements may be impossible to see because the background and border (if any) both match the surrounding background color.

Perhaps a more practical solution would be to enforce some minimum border (using the user's preferred, or system, foreground color) when form elements are styled and the user doesn't allow pages to use their own colors.

[Bzbarsky (bzbarsky)]

It sounds like the real problem is that we're using a system color for the text but not for the background or something? At least once we drop native theming...

That's odd, though. forms.css certainly uses a system color for the background _and_ the text. So the browser color settings shouldn't matter.

[Bzbarsky (bzbarsky)]

Ah, I see what's going on here. The author rule is higher precedence than the forms.css rule. So we see that ruledata first. We're ignoring it, and it has a background color style, so we set the background to user default (in this case black). We do NOT set the color.

Then we process the ua rule. There is already a background set, so the ua background is ignored. But we do use the -moz-fieldtext color (in this case also black).

We should probably also force the foreground color when we force the background.... Or something.

[Kliu (kliu)]

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

[Kliu (kliu)]

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

[Yehudab (yehudab)]

(In reply to comment #9)
> *** Bug 423954 has been marked as a duplicate of this bug. ***
>

Some background material from bug 423954, in order to make the X in " wanted1.9.0.x" to be as low as possible:

This bug is not about teenage boys who like to see everything in black, or teenage girls who like to see everything in pink. It is about giving people with sight impairment accessibility to the internet. See http://www.webaim.org/articles/visual/lowvision.php#fontsandbackground for a detailed explanation.

On top of that, Federal US lows (section 508) require that software programs and operation systems support this kind of user selectable colors. This means that Firefox 3.0.0 cannot be installed in any US Federal agency (I know that Firefox penetration in those places is low, but it might make it even lower). I guess that other countries have similar rules or regulations.

[Kliu (kliu)]

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

[Giuseppe Pennisi (giupenni78)]

I can confirm this bug.
When I use a dark theme, the menuitem in the menubar not changes the font color in accord with gtk theme.

gp

[Musthafa Meeran (musthafameeran-deactivatedaccount)]

I also have this problem (dark letters in dark background in the input boxes, menu items etc).

I really like black themes, but because of this, I have to revert to the good old human theme !!

[Phiw (phiw)]

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

[Bzbarsky (bzbarsky)]

I tried giving this a shot, but the problem is that we resolve the color and background structs separately. So we have no way to know that we clobbered the background when we go to get the color...

Maybe we should just set explicitly the color to default whenever there's an author-winning color and be done with it?

[Bzbarsky (bzbarsky)]

Created attachment 336718
Patch to do that

This reintroduces bug 58048 for only those form controls which the author styles. Right now we have it for their backgrounds but not their colors, which can easily read to unreadable combinations. So this is an improvement, though not much of one.

[L. David Baron (dbaron)]

So I think what we should do here, ideally, is make author setting of background-color set the background-color to the background-color the nearest ancestor of the element (including itself as an ancestor) that has a non-transparent background color from the user or user agent style sheets.

I think that's hard, although I'd like to think about it a little more...

[L. David Baron (dbaron)]

What about the following alternative:

Make nsPresContext::HasAuthorSpecifiedRules begin with:

  if (!UseDocumentColors())
    return PR_FALSE;

Does that help?

[Bzbarsky (bzbarsky)]

That would mean not dropping native theming when authors change the border style or width, or padding, if they're prohibited from changing colors. The width and padding thing in particular could cause issues, I think.

[L. David Baron (dbaron)]

What about removing the background bit from the bitmask in that case?

[Bzbarsky (bzbarsky)]

That sounds much more promising. Lemme sleep on it and test the effect tomorrow.

[Bzbarsky (bzbarsky)]

That doesn't work, because the testcase also styles the border. So we drop native theming anyway, and then follow the codepath in comment 7.

[Phiw (phiw)]

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

[Tchalvak (tchalvak)]

Created attachment 352788
Dropdown menus with dark background don't change the text to contrast.

Dark theme in ubuntu firefox 3.0.4, chrome still doesn't respect the dark theme by having contrasting text on its dropdowns, dark dropdowns with nearly unreadable dark text result.

[Tchalvak (tchalvak)]

Hmmm, for whatever reason the project says seamonkey, so perhaps this is the wrong bug for the firefox issue in firefox 3.

[Tchalvak (tchalvak)]

I really think that the upstream bug was assigned wrong, it's a bug against the "seamonkey" project from 2001, that can't be right, can it?

[Tchalvak (tchalvak)]

I'm having this issue as well, from the description of 't all, sounds like a perfect acessment of the problem is under way (even if a final solution isn't at hand yet). My system theme is respected for the dropdown chrome, but not for the dropdown text, resulting in dark on dark dropdown boxes.

A simple example image is loaded downstream in launchpad, viewable here:
http://launchpadlibrarian.net/20391950/darkDropdownsHaveDarkText.png

With the bug:
https://bugs.launchpad.net/ubuntu/+source/firefox-3.0/+bug/220263

[Tchalvak (tchalvak)]

I added a more appropriate firefox/mozilla bug report to this launchpad entry:
https://bugzilla.mozilla.org/show_bug.cgi?id=437366
Which seems to describe not only the exact problem that I've detailed in the png image above, but also they've been looking at possible solutions, and it's had comments from people looking to fix the problem within the last year so there's probably the place to make a comment if you've got one.

[Tchalvak (tchalvak)]

Created attachment 352794
When using a dark system theme, Dark dropdowns have dark text, as per the images and bug filed on launchpad.

[Tchalvak (tchalvak)]

Just to add to the assessment, it looks like a lot of the chrome elements interpret the system settings just fine, for example the chrome of the "Commit" button below the Additional Comments window that I'm writing in now shows just fine (with white text on the system-colored dark chrome), so perhaps duplicating whatever behavior the normal submit button chrome is using would fix the problem with the dropdowns.

[Bzbarsky (bzbarsky)]

Tchalvak, we know exactly why _this_ bug is happening. If you're seeing something other than this bug, please file a separate bug report.

[L. David Baron (dbaron)]

Comment on attachment 336718
Patch to do that

OK, r+sr=dbaron. Sorry for thinking about it for so long.

But please file a followup bug on fixing form controls.

(I'm a little surprised we don't have a test for this... any chance you could add one?)

[Bzbarsky (bzbarsky)]

> But please file a followup bug on fixing form controls.

Fixing what, exactly? The bug 58048 regression?

I'll see what I can do as far as a testcase goes.

[Bzbarsky (bzbarsky)]

Pushed http://hg.mozilla.org/mozilla-central/rev/f87b46d44d22 on m-c.

[L. David Baron (dbaron)]

(In reply to comment #27)
> Fixing what, exactly? The bug 58048 regression?

Yes.

It's also worth getting this into 1.9.1.

[Bzbarsky (bzbarsky)]

I filed bug 471345 (and requested branch approvals for this patch).

[L. David Baron (dbaron)]

Hmmm. I think bug 471520 is probably a bad enough regression that we should back this out. I should have thought of that...

I'm also actually not so sure comment 17 is that bad. The only thing that it would be a problem for is border (we don't drop native theming for padding or width), and I'm not sure that's such a big problem.

[Beltzner (beltzner)]

Comment on attachment 336718
Patch to do that

(As dbaron mentions, we can't take this on branch until the regression in bug 471520 is handled.)

[Bzbarsky (bzbarsky)]

I backed out attachment 336718.

I guess if we're not worried about border width changes messing up layout (which I think I can live with), we can do comment 16.

[Bzbarsky (bzbarsky)]

Created attachment 355502
Per comment 16

I did test that this works fine.

[L. David Baron (dbaron)]

Comment on attachment 355502
Per comment 16

r+sr=dbaron

[Bzbarsky (bzbarsky)]

Pushed http://hg.mozilla.org/mozilla-central/rev/fc12d81653dd

[Bzbarsky (bzbarsky)]

Comment on attachment 355502
Per comment 16

This should be a much safer fix than the other that we tried.

[Beltzner (beltzner)]

Comment on attachment 355502
Per comment 16

a191=beltzner

[Bzbarsky (bzbarsky)]

Pushed http://hg.mozilla.org/releases/mozilla-1.9.1/rev/0a9f0a5ee334

[Samuel-sidler+old (samuel-sidler+old)]

Boris, does your patch apply to 1.9.0?

[Bzbarsky (bzbarsky)]

Comment on attachment 355502
Per comment 16

Yes. I suppose we should take it there too.

[Dveditz (dveditz)]

Comment on attachment 355502
Per comment 16

Approved for 1.9.0.7, a=dveditz for release-drivers.

[Bzbarsky (bzbarsky)]

Fixed on 1.9.0 branch.

[CaptainInsaino (david-geraghty)]

I had the same problem. The following userContent.css file fixes it:

http://blog.fekw.de/2008/06/16/kde-dark-theme-and-firefox-2-3-usercontentcss/

It seems that the "-moz-appearance: none" lines are all important.

[Musthafa Meeran (musthafameeran-deactivatedaccount)]

Thanks a lot.. the above link fixed all my issues !!!

On Sun, Feb 1, 2009 at 7:00 AM, CaptainInsaino
<email address hidden>wrote:

> I had the same problem. The following userContent.css file fixes it:
>
> http://blog.fekw.de/2008/06/16/kde-dark-theme-and-
> firefox-2-3-usercontentcss/<http://blog.fekw.de/2008/06/16/kde-dark-theme-and-%0Afirefox-2-3-usercontentcss/>
>
> It seems that the "-moz-appearance: none" lines are all important.
>
> --
> Bad Firefox integration with dark themes
> https://bugs.launchpad.net/bugs/220263
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Mozilla Firefox Browser: Fix Released
> Status in XUL + XPCOM application runner: Confirmed
> Status in "firefox-3.0" source package in Ubuntu: Triaged
>
> Bug description:
> I'm using Mozilla Firefox 3 Beta 5 on Ubuntu 8.04 with a dark theme. Now I
> see all the input boxes and buttons filled with grey colour. This happened
> even with Firefox 2, but I solved that problem with a quick guide under the
> comment "firefox fix" by Proton at the bottom of this page:
> http://www.gnome-look.org/content/show.php/Grey+Neu?content=60824
>
> In Firefox 3 I can't correct this problem.
>

[Lutz (webmaster-phatsonic)]

Confirmed. That did it - almost.
The only input still missing is the file-upload field.

So the -moz-appearance lines were the ones missing in my file...

Thanks, CaptainInsaino! :)

P.S.: It still sucks, that 70% of the the webdesigners don't care about providing clean stylesheets (Yes, Canonical. You too). You can't just assume that all browsers will have the same default colors. So if you want a color in your site - specify it, damnit.

[Musthafa Meeran (musthafameeran-deactivatedaccount)]

Yeah, Confirming that the file-upload is still an issue.

Thanks.....

On Sun, Feb 1, 2009 at 8:41 PM, Lutz <email address hidden> wrote:

> Confirmed. That did it - almost.
> The only input still missing is the file-upload field.
>
> So the -moz-appearance lines were the ones missing in my file...
>
> Thanks, CaptainInsaino! :)
>
> P.S.: It still sucks, that 70% of the the webdesigners don't care about
> providing clean stylesheets (Yes, Canonical. You too). You can't just
> assume that all browsers will have the same default colors. So if you
> want a color in your site - specify it, damnit.
>
> --
> Bad Firefox integration with dark themes
> https://bugs.launchpad.net/bugs/220263
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in The Mozilla Firefox Browser: Fix Released
> Status in XUL + XPCOM application runner: Confirmed
> Status in "firefox-3.0" source package in Ubuntu: Triaged
>
> Bug description:
> I'm using Mozilla Firefox 3 Beta 5 on Ubuntu 8.04 with a dark theme. Now I
> see all the input boxes and buttons filled with grey colour. This happened
> even with Firefox 2, but I solved that problem with a quick guide under the
> comment "firefox fix" by Proton at the bottom of this page:
> http://www.gnome-look.org/content/show.php/Grey+Neu?content=60824
>
> In Firefox 3 I can't correct this problem.
>

[Abillings (abillings)]

Verified for 1.9.0.7 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.0.7pre) Gecko/2009021705 GranParadiso/3.0.7pre (.NET CLR 3.5.30729).

[Bstriker (bstriker)]

Created attachment 405248
Firefox 3.5 vs Dark GTK theme

Confirm the bug on Ubuntu 9.04, GNOME 2.26.1, 'New wave' built-in theme

[Krishna Kumar Deep (krishnakumardeep)]

Created attachment 811101
Bug70315Fx24.png

The bug is still present in Firefox(24.0).

[Spyro-boy (spyro-boy)]

Honestly, I understand the complexity of this issue but can we just make Firefox ignore the GTK theme completely from within the viewport? I don't think it makes sense to make the GTK theme dictate what is going on inside of the viewport.

[Spyro-boy (spyro-boy)]

To clarify, instead of Firefox trying to make an informed decision based on the system/GTK theme, can Firefox just default to the colours specified in the Content tab in Colors and pretend that GTK doesn't exist? (only in the viewport)

the only alternative to this problem is to install extensions that allow the user to override page themes but that is ultimately messy and can also break things in unexpected ways.

[Matei-tene-0 (matei-tene-0)]

I too am also affected by this (seemingly old) bug, on an Ubuntu Gnome 15.04 using the built-in dark theme. Some text boxes result in using white text on a white background, since Firefox uses a mixture of the webpage CSS and that from the GNOME theme.

Dario's suggestion above is sensible, since webpages were meant to look the same, regardless of OS/System/Theme.

[Matthew Hoener (ionsquare)]

As Dario said, it doesn't make sense to use the GTK theme on web pages. In addition to this, there is *already* a setting for not using the system colours:

Edit > Preferences > Colors > Use system colors

I believe it is off by default and obviously should prevent the system colour scheme from determining form field background colours, but it doesn't.

Seems to be the same issue as in bug 519763, similarly disappointing progress there as well though.

[Matthew Hoener (ionsquare)]

For what it's worth, there is a very clean workaround in the ArchWiki:

https://wiki.archlinux.org/index.php/Firefox#Unreadable_input_fields_with_dark_GTK.2B_themes

I had seen some other userContent.css "fixes" that didn't get everything or overrode too much, breaking legit stylesheets, but this seems to only override the default and shouldn't override any actual website css.

[je-vv (je-vv)]

I've tried that work around on form fields on my bank account, and they don't work. Actually GnomishDark theme also provides several recommendations under:

/usr/share/themes/GnomishDark/README

Which mozilla ones are almost the same suggested by the Arch workaround, and I've also been using for quite a while now.

They don't work with FF 45.0.1 and gtk+3 3.20.2 setting gtk+3 to prefer applications' dark themes and to use the dark theme GnomishDark.

However it doesn't work on nvidia graphics, but seems to be working on intel graphics with the same settings...

[je-vv (je-vv)]

Though my problem is different though, the backgorund is white and the font is white as well

[Luis Mondesi (lemsx1)]

I'm using Firefox 46.0+build5 on Ubuntu 16.04 and this bug just hit me after many years of using the global dark theme (Adwaita + Humanity Dark icons).

If I turn off the "Global Dark Theme" in Gnome tweak tool, everything is back to normal in Firefox.

It seems to me that the bug is somewhere in /usr/share/themes/Adwaita/gtk-2.0/gtkrc.

Essentially, going to pages like this https://net-ssh.github.io/scp/v1/api/classes/Net/SCP.html is completely unreadable. If I highlight the invisible text, I'm able to see there is something there whose color matches the background color!

In other words, it's not useful to mess with the default web page colors to try to make the "dark" theme work 100% of the time across all kinds of webpages. That's only 1 example of many places where this new theme has broken functionality. Some forms present unreable or "invisible" inputs!!

[Luis Mondesi (lemsx1)]

Example view from https://net-ssh.github.io/scp/v1/api/classes/Net/SCP.html

[Anders Kaseorg (andersk)]

Firefox 47 worked around this by disabling the dark theme entirely.

Firefox 55 beta supports two new independent about:config settings, widget.chrome.allow-gtk-dark-theme and widget.content.allow-gtk-dark-theme (https://bugzilla.mozilla.org/show_bug.cgi?id=1158076). The former gets you a dark-themed UI without messing up web page content.

Official PPA for Firefox beta, if you don’t want to wait: https://launchpad.net/~mozillateam/+archive/ubuntu/firefox-next

[Hewanci (hewanci)]

The fact that Firefox cannot handle dark desktop themes was reported many times FOR SEVENTEEN YEARS.

Seventeen years. And still an issue.

Webpages display partly in system colors causing white on white or black on black text/form elements, while parts of the Firefox UI defy every dark theme and stay eye-bruning white.

I hoped that finally Quantum will fix this... but it MADE IT WORSE!

Now several parts of the FF GUI have white on white checkboxes or disabled text, and everything in settings is blazing white as well as new tab page.

All you need to do to fix the websites is to use the widespread defaults instead of system colors to render webpages.

color:black;
background-color:white;

DONE.

But you can't do this for 17 years for reasons beyond comprehension.

WORKS in Chrome (USES GTK TOO!)
WORKS in Internet Explorer
WORKS in Microsoft Edge
WORKS in pretty much EVERYTHING other than Firefox.

Just a few tickets about problems with dark themes, in order:

https://bugzilla.mozilla.org/show_bug.cgi?id=70315 <--- 17 years old report!!! Still "New"!
https://bugzilla.mozilla.org/show_bug.cgi?id=1195138
https://bugzilla.mozilla.org/show_bug.cgi?id=1268338
https://bugzilla.mozilla.org/show_bug.cgi?id=1283086
https://bugzilla.mozilla.org/show_bug.cgi?id=1379725
https://bugzilla.mozilla.org/show_bug.cgi?id=1385518
https://bugzilla.mozilla.org/show_bug.cgi?id=1391007
https://bugzilla.mozilla.org/show_bug.cgi?id=1393927
https://bugzilla.mozilla.org/show_bug.cgi?id=1402312
https://bugzilla.mozilla.org/show_bug.cgi?id=1408121
https://bugzilla.mozilla.org/show_bug.cgi?id=1414693
https://bugzilla.mozilla.org/show_bug.cgi?id=1415511
https://bugzilla.mozilla.org/show_bug.cgi?id=1418090
https://bugzilla.mozilla.org/show_bug.cgi?id=1424422
https://bugzilla.mozilla.org/show_bug.cgi?id=1425161
https://bugzilla.mozilla.org/show_bug.cgi?id=1425517

[Rimas-1 (rimas-1)]

Dear Storm,

1. Putting same heated rant in multiple bugs is one good way to achieve two things: a) earn a ban from commenting on this Bugzilla, and b) decrease the likelihood of these bugs being fixed by blurring their scope. I mean, it's surely the easy thing to do, whereas a much more constructive and useful thing would be to figure out which of these issues are duplicates of each other, or have lost focus over time, and propose merging or closing them. For example, this bug seems to have become a catch-all for anything dark_theme-related, and IMO is as good as closed by now anyways, whereas bug 119538 is actually about Firefox for Android, which is a separate product, has nothing to do with GTK, and is irrelevant in any discussion where particular issues on GTK, Windows or Mac are involved. Similarly, bug 1425517 is about Calendar (built-in Thunderbird extension), and as such has very little relevance to Firefox.

Another good thing to do would be to file new bugs if you stumble upon issues which aren't on the record yet. The narrower the issue, the more chance you have of it being taken seriously and fixed. You know, because fixing "OMG NOTHING WORKS YOU ALL SUCK" is kinda more difficult than fixing "Checkboxes in this particular dialog are illegible when using dark theme, here's a screenshot and more info".

Oh, and of course, you could have proposed a patch instead of complaining.

2. Content colors are user-managed, and default to black-on-white: https://support.mozilla.org/en-US/kb/change-fonts-and-colors-websites-use#w_change-font-color. The option to "Use system colors" is NOT checked by default, and it has always been this way.

3. On the other hand, form fields have always inherited the system-wide look by default. Mozilla even has it documented: https://developer.mozilla.org/en-US/docs/Learn/HTML/Forms/Styling_HTML_forms.

3. Illegible text, whether in form fields or elsewhere, is pretty much ALWAYS the designer's (or rather person's who did the CSS work) fault. It's a rule of thumb that if you're specifying background color, you should also specify text color, and vice-versa. Back in the day, people used to validate their CSS, and specifying just one of those colors would trigger a warning in the validator. Nowadays, everyone just blindly assumes that stuff will work after minimum testing on Chrome, and then blames whatever doesn't work in the other browser on that other browser.

Now, aside from all that, I suppose a desire to use back-on-white on form widgets by default (so long as "use system colors" is unchecked) could be a valid feature request. I doubt this would be easy to implement though, especially assuming that some people might prefer native look.

[Hewanci (hewanci)]

Dear Rimas Kudelis,

Let me answer each of your points. I'll leave point 1; to the last

> 2. Content colors are user-managed, and default to black-on-white:
> https://support.mozilla.org/en-US/kb/change-fonts-and-colors-websites-
> use#w_change-font-color.

FALSE. Those colors have _nothing_ to do with default colors. They are override colors, that, when apply, override websites' CSS as well. By default they only apply with HighContrast theme, and no, "use system colors" is NOT enabled on my FF.

I just set those colors to bright red and neon green - guess what? Writing a review on addons.mozilla.org is _still_ light gray on white. And that light gray is my system color, which shouldn't apply, yet it does.

Ever since I use Firefox with a dark theme (about 10+ years) this was broken. And currently there is no any way I know of, or that I could find via hours of Googling, to change the default colors Firefox falls back to if no color is specified.

> 3. On the other hand, form fields have always inherited the system-wide look
> by default.

And they shouldn't. Appearance, sure, but NOT colors. Colors of the host system should not, ever, under any circumstance affect the colors displayed in webpages, since webpages' look is independent of the host system.

> 3. Illegible text, whether in form fields or elsewhere, is pretty much
> ALWAYS the designer's (or rather person's who did the CSS work) fault.

I disagree partly. It is their fault that they didn't specify colors, and relying on the assumption that if no color is specified then background will be white and text will be black.

But it is not their fault, that this assumption is true in every single browser, except Firefox with dark theme. It is also not their fault, that Firefox, instead of implementing these common expectations as default, lets system colors bleed into webpages. And since we know that many-many webdesigners will be lazy, why not save our users from all that pain by implementing sane defaults?

Also, it's funny how parts of mozilla.org are affected by this issue.

> Back in the day, people used to validate their CSS
And in a perfect world they would still do it, but we are not living in a perfect world sadly, so we may as well account for that instead of sticking heads into the sand.

> Nowadays, everyone just blindly assumes that stuff will
> work after minimum testing on Chrome
If they don't have a dark system theme, it will work for them in every single browser in existence. Only Firefox, combined with dark system theme does break it.

So back to 1;

I'm desperate. I started using Firefox about 15 years ago because it was the best, and_most_customizable_ browser out there. It had its flaws, but we loved it regardless.

I had high hopes for Quantum, but instead it was a gigantic let down.
 - It killed off several amazing Addons, that are impossible to port to WebExtension because it's extremely limited.
 - Addon devs' feature requests for functionality allowing said mods to be ported were simply closed with "WONTFIX".
 - Even more customization was removed, partly by making it impossible for Addons to customize FF now (eg. Classic Theme Restorer with millions of user...

[Jason C. McDonald (codemouse92)]

I wholly agree with Storm's assessment. As a programmer, a web developer, and a UI designer, the fact that Firefox has sat on this bug for over a decade is shameful, especially since it has been *patched* with extensions before.

For anyone affected, install the "Text Contrast for Dark Themes" (https://addons.mozilla.org/en-US/firefox/addon/text-contrast-for-dark-themes/?src=api) extension. I've been using it for the past few weeks, and it resolves 98% of the problems related to this bug.

The fact that extension exists should NOT be taken as an excuse for Firefox not to fix this. If anything, it means that Firefox developers have even *less* excuse for taking care of the problem, since the patch code is in the extension!

[Qwerty Chouskie (asdfghrbljzmkd)]

Please, Firefox devs, fix this! With the rise of themes like Arc-dark, this is a HUGE issue! I just want things to look normal! Is that so much to ask?

*begging puppy eyes*

[harry (vaaghoofdharry)]

Yeah pretty weird this is still an issue, should be pretty easy to fix. In the mean time. Meanwhile, this fixed my problem:
https://github.com/lightradius/firefox-dark-theme-fix

(backup your profile, then place the userContent.css file in your ~/.mozille/firefox/XXXXXXXX.default/chrome directory - create it if it doesn't exist)

[Matei-tene-0 (matei-tene-0)]

(In reply to vaaghoofdharry from comment #39)
> Yeah pretty weird this is still an issue, should be pretty easy to fix. In
> the mean time. Meanwhile, this fixed my problem:
> https://github.com/lightradius/firefox-dark-theme-fix
>
> (backup your profile, then place the userContent.css file in your
> ~/.mozille/firefox/XXXXXXXX.default/chrome directory - create it if it
> doesn't exist)

This is a major improvement already and can also be used in Thunderbird.
The directory (on Ubuntu) is ~/.thunderbird/XXXXXXX.default/chrome, which didn't exist initially.

Would like to see a built-in complete solution to this for both Firefox and Thunderbird.

[Adomas-dev (adomas-dev)]

Just want to confirm that this bug is still NOT fixed. I use KDE Plasma desktop enviroment with Breeze Dark color scheme. Usually I use Chromium, sometimes Google Chrome, as they don't have issues with dark themes. But I want to use Firefox and because of this bug I can't. I was following Firefox releases past 4-5 years expecting to see a fix for this.

Now I use "Text Contrast for Dark Themes" extension which kind of helps, but not enough for daily use.
https://addons.mozilla.org/en-US/firefox/addon/text-contrast-for-dark-themes/

It's sad to see that this bug already 17 years old and does not get enough attention to get fixed.

As dark themes for GTK+ getting more popular, I hope to see a fix in future. Could be set as a milestone for 2020 or something, that would be really great! No other browser has this issue, only Firefox.

If this is super hard to fix, maybe would be good idea to switch to another toolkit instead of GTK+? For example Qt toolkit is very good, has a lot of support and works pretty well.

OFFTOPIC: One thing made me happy with recent Firefox releases, that HighDPi display support is improved, and it's possible to get non-integer value scaling of UI and websites. For that I was waiting 2 years and I am really happy it got improved. To get Dark Theme compatibility would be last step to make Firefox usable for me and some other users!

[killown (systemofdown)]

Still not fixed, what an annoying bug

[Bruno Pagani (b-pagani)]

The best workaround I’ve found yet:
https://www.reddit.com/r/firefox/comments/6rbvvw/photon_rectangular_tabs_have_landed_in_nightly/dl4318f/

[Bad-banana (bad-banana)]

bump!

i can't believe a small nuisance is taking 17 years not fixed.

workaround
https://www.reddit.com/r/firefox/comments/6rbvvw/photon_rectangular_tabs_have_landed_in_nightly/dl4318f/

[L. David Baron (dbaron)]

I suspect that many aspects of this actually were fixed at various times. But the hard part is to prevent all the CSS changes in the browser front-end from triggering some aspect of it again. (At one point I think I'd made a testing mode in which the correct foreground/background pairs were always the same color, so that no text should be visible, that could be used to check that colors were matched correctly. I'm not sure if I even landed the code for it or what happened to it since.) I'd also done some work to document what those pairs were, i.e., the rules for which native-theme-derived foreground color should be matched with which background color so that themes work correctly. (-moz-appearance makes this a bit more complicated, since foreground colors could be matched with a -moz-appearance background as well.)

The number of comments recently makes me suspect that something got *worse* recently.

In theory fixing this probably requires:
 * documenting what the valid foreground-color and (background-color or -moz-appearance) pairs are for use of colors from native themes
 * developing a mechanism to check that the UI uses only those pairs together and nothing else (probably by making each pair render the same (bright) color as a diagnostic
 * auditing the Firefox UI
 * checking that the things we're extracting from GTK themes make sense with the rules that we're applying

[Evan Klitzke (eklitzke2)]

(In reply to David Baron :dbaron: ⌚UTC+2 from comment #45)
> The number of comments recently makes me suspect that something got *worse*
> recently.

Yes, something did change in GNOME recently. Prior to GNOME 3.28 there was a GTK preference called gtk-application-prefer-dark-theme that could be used to get dark widgets. This could either be set in ~/.config/gnome-terminal/gtk-3.0/settings.ini. This was also exposed as a toggle option in the gnome-tweaks tool, which is probably how most users had set it it. This GTK option has been deprecated in GNOME 3.28, and the new way to get a dark theme is to explicitly set one's GTK theme to Adwaita dark. You can read about this a bit more at [1] and [2].

Firefox apparently has some logic to ignore gtk-application-prefer-dark-theme, but that logic no longer works on GNOME 3.28 with the Adwaita dark theme. As was mentioned in comment #43, the work around for GNOME 3.28 is to set a user pref (i.e. in about:config or user.js) that sets widget.content.gtk-theme-override to Adwaita:light.

As I suspect the overwhelming majority of Firefox users with dark GTK themes are using Adwaita dark (which is bundled with GNOME), I would suggest updating the Firefox dark them detection logic to handle the new case with the Adwait theme names hard coded. This is hacky, but probably mitigates the issue for most users.

[1] https://jeremy.bicha.net/2017/08/29/gnome-tweaks-3-25-91/
[2] https://jeremy.bicha.net/2018/01/29/gnome-tweaks-3-28-progress-report-1/

[Evan Klitzke (eklitzke2)]

I've got a patch up to try to mitigate the issue for GNOME 3.28 over at bug #1461538.

[Jonathan Lane (jwlane)]

Evan, what that patch will not do is fix the input field issue on explicitly chosen dark themes. What I would recommend instead is simply making this bit of userContent.css equivalent completely override Gtk regardless of theme, to produce the desired output:

INPUT, TEXTAREA {color: black ; background: #ffffff ; }

This is the general case which websites expect, and which users expect, and in my testing does not interfere with sites that explicitly set up a different color combination for text input areas. I don't even think it's -possible- to recreate this bug on the Windows or Mac ports without manually messing with userContent.css, so forcibly overriding Gtk here seems like the intelligent thing to do.

[Abhishek Madhu (abhishek.madhu)]

(possible way to solve this issue?)

Sir,
One option might be to remove all dependency on system themes.
Firefox shouldn't care about the system themes. No dependence.

All text should be rendered:
    1. like the .css developer wanted
or, 2. if he uses !important, render it simply black on white.

In a nutshell, default FF canvas(for everything, including input boxes) and font should be white and black respectively.
We shouldn't inherit this from the system theme. Why should we? Do we really need to?

Hope this would nullify @dbaron sir's requirements and make it easier to implement this, sooner.

Thank You

[Please do not ban me if this does not help. Ping me and I'll remove it myself.
This is my first time coming out with ideas as stupid as this :)]

[Yuri Khan (yurivkhan)]

I predict that Apple is going to fix this bug in a few years, by evangelizing @media(prefers-color-theme: dark) all over the Web.

[Pedro Côrte-Real (pedrocr)]

I hit this bug today by choosing the dark Adwaita theme in Gnome 3.28 and Firefox 65.0. It's amazing that this is an 18 year old bug. I found it surprising the system theme did anything to webpages and had two consecutive surprises:

- First setting the system theme to Adwaita-dark changed the Firefox theme. That makes sense. What was surprising was that the Firefox theme then changed the content of the web pages. My mental model of a browser is that within the page view it's a different world and there's no reason for the web to look different to match the browser chrome or the system theme.
- Because I didn't actually like the dark version of Firefox I switched it to the Light theme manually (webpages are usually light colored and so dark chrome in browsers looks weird). And yet even after doing this pages still had dark buttons and input areas. That was even stranger. Now Firefox had a light theme and yet the webpages were still picking up broken colors from the system theme inconsistent with the Firefox chrome theme.

I fixed this after some web searches by setting "widget.content.gtk-theme-override:Adwaita". That at least sets a light theme for UI controls and is back to looking reasonable. I found that in bug #1283086 which seems to be a 3 year old duplicate of this 18 year old bug. The proposal for removal of all native theming in #1411425 makes perfect sense.

[Qwerty Chouskie (asdfghrbljzmkd)]

In the mean time, could `widget.content.gtk-theme-override` be set to `Adwaita` by default? This would fix the issue (except for the settings page), and Adwaita is always present on systems with GTK+. I opened https://bugzilla.mozilla.org/show_bug.cgi?id=1527048 for this change, everyone please go comment on that bug :)

[L. David Baron (dbaron)]

So I think it would be useful to know, for the current round of complaints, are the problems the result of:

1. Firefox incorrectly gets data out of the GTK theme, so that its default appearance for controls doesn't match the native one, or
2. Firefox gets the data out of the theme correctly, but then web pages override one but not both of color and background (while assuming that color is dark and background is light), leading to an unreadable result

We've had both problems in the past, and it would be useful to know which of them is happening in the set of problems that have spiked in the past few months.

[Klingt-net+mozilla (klingt-net+mozilla)]

I use this extension as a workaround: [fix-dark-theme-input-boxes](https://addons.mozilla.org/en-US/firefox/addon/fix-dark-theme-input-boxes/) ([source](https://gitlab.com/Roboe/userscripts/tree/master/fix-dark-theme-input-boxes/))

[Qwerty Chouskie (asdfghrbljzmkd)]

David: The problem here is point 2. Just setting `widget.content.gtk-theme-override` to `Adwaita` by default would fix this for web pages, but the General -> Startup section of the Settings page still looks wrong (white text on a white background), along with a couple of other spots in Settings, despite setting this pref.

[Benjamin Robinson (g-ben-j)]

If you uncheck "Use System Colors" it's no longer a problem.

[Pedro Côrte-Real (pedrocr)]

I have "Use System Colors" unchecked, `widget.content.gtk-theme-override` set to `Adwaita` and the Light theme selected. And yet even then the Ctrl-F input has white text over white background.

[L. David Baron (dbaron)]

re comment 57, with those settings (on Ubuntu 18.04), I see white text on a dark background.

[Pedro Côrte-Real (pedrocr)]

I'm also using Ubuntu 18.04 but using the vanilla GNOME session (that uses Wayland) with the dark Adwaita theme selected. Could you please test with that to see if you get the same result?

[Stransky (stransky)]

System colors (and it's override) is covered by Bug 1422563
Dark Gtk theme is covered by Bug 1527048

[Stransky (stransky)]

btw. widget.content.gtk-theme-override should be set to "Adwaita:light" and works only when e10s is enabled.

[Pedro Côrte-Real (pedrocr)]

I seem to have e10s enabled:

Multiprocess Windows 1/1 Enabled by default

and have set Adwaita:light:

widget.content.gtk-theme-override;Adwaita:light

I still get white text on white background on the Find textbox within webpages.

[Pedro Côrte-Real (pedrocr)]

Here's a simple way to replicate this bug for me. In both cases I have the Light theme selected:

$ GTK_THEME="Adwaita:dark" firefox
(firefox runs and the Find box has white text on white background)

$ GTK_THEME="Adwaita:light" firefox
(firefox runs and the Find box has the correct black text on white background)

[Scott Palmer (skewty)]

I am having this issue with Firefox 66.0.3 using Ubuntu 19.04 (Gnome 3.32 using Adwaita dark).

This release seems to ignore:

  widget.content.allow-gtk-dark-theme in about:config is set to default / false
  widget.chrome.allow-gtk-dark-theme in about:config is also default /false

I came back to Firefox after running Brave for a bit only to find this....
Is this just another Mozilla blunder? Time to install Brave again.

[Scott Palmer (skewty)]

For those that run linux and want to update their Firefox icon so it automatically launches with GTK_THEME="Adwaita:light" firefox %u instead (band-aid work around that shouldn't need to be).

$ cp /usr/share/applications/firefox.desktop ~/.local/share/applications
$ gedit ~/.local/share/applications/firefox.desktop

Change the "Exec=" line to read:

Exec=bash -c "GTK_THEME=\"Adwaita:light\" firefox %u &"

Save and Exit.
Now your Firefox icon should start using the Adwaita:light theme without a lingering terminal window.

[Qwerty Chouskie (asdfghrbljzmkd)]

This should be fix as of https://bugzilla.mozilla.org/show_bug.cgi?id=1527048#c14

Testing appreciated.

[Asif Youssuff (yoasif)]

Can this be resolved fixed due to Bug 1527048 being fixed?

[Stransky (stransky)]

Yes, duplicate of Bug 1527048.

*** This bug has been marked as a duplicate of bug 1527048 ***