Bad Firefox integration with dark themes
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Mozilla Firefox |
Fix Released
|
High
|
|||
XULRunner |
Invalid
|
Medium
|
|||
firefox (Ubuntu) |
Triaged
|
Low
|
Unassigned |
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://
In Firefox 3 I can't correct this problem.
In Mozilla Bugzilla #70315, Zach-zachlipton (zach-zachlipton) wrote : | #1 |
In Mozilla Bugzilla #70315, Asa (asa) wrote : | #2 |
updating to new owner. sorry for the spam.
In Mozilla Bugzilla #70315, Q-daemonc-netscape-net (q-daemonc-netscape-net) wrote : | #3 |
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.
In Mozilla Bugzilla #70315, L. David Baron (dbaron) wrote : | #4 |
What's the name of the GTK theme you use where you see the problems?
In Mozilla Bugzilla #70315, Q-daemonc-netscape-net (q-daemonc-netscape-net) wrote : | #5 |
Any theme with a dark background and white text will do.
In Mozilla Bugzilla #70315, Q-daemonc-netscape-net (q-daemonc-netscape-net) wrote : | #6 |
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,
In Mozilla Bugzilla #70315, L. David Baron (dbaron) wrote : | #7 |
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?)
In Mozilla Bugzilla #70315, L. David Baron (dbaron) wrote : | #8 |
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/
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_
+ aColor = GDK_COLOR_
break;
// from the CSS3 working draft (not yet finalized)
In Mozilla Bugzilla #70315, Q-daemonc-netscape-net (q-daemonc-netscape-net) wrote : | #9 |
Just so everyone knows, text boxes are still completely unreadable in many GTK
themes, and 8.1 will be out in a few days.
In Mozilla Bugzilla #70315, L. David Baron (dbaron) wrote : | #10 |
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?
In Mozilla Bugzilla #70315, Q-daemonc-netscape-net (q-daemonc-netscape-net) wrote : | #11 |
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.
In Mozilla Bugzilla #70315, Matthew Paul Thomas (mpt) wrote : | #12 |
--> 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.
In Mozilla Bugzilla #70315, P-ch (p-ch) wrote : | #13 |
isn't that fixed? at least, with FB gtk2 it is.
In Mozilla Bugzilla #70315, Pde-cs (pde-cs) wrote : | #14 |
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.
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.
In Mozilla Bugzilla #70315, Rui Matos (tiagomatos) wrote : | #15 |
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.
In Mozilla Bugzilla #70315, Rui Matos (tiagomatos) wrote : | #16 |
Created attachment 293395
URL dropdown with almos unreadable text
See above.
In Mozilla Bugzilla #70315, Rui Matos (tiagomatos) wrote : | #17 |
What's this bug status regarding the Firefox 3 release?
In Mozilla Bugzilla #70315, Twentyafterfour+bz (twentyafterfour+bz) wrote : | #18 |
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
In Mozilla Bugzilla #70315, glen (webplate) wrote : | #19 |
Created attachment 312077
The awesomebar with the darkilouche theme...
The green urls are almost unreadable...
In Mozilla Bugzilla #70315, glen (webplate) wrote : | #20 |
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) wrote : | #21 |
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://
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://
In Firefox 3 I can't correct this problem.
Alexander Sack (asac) wrote : | #22 |
can you please upload those images to launchpad as attachment to this bug?
Changed in firefox: | |
status: | New → Incomplete |
Luca Livraghi (luca91) wrote : | #23 |
Luca Livraghi (luca91) wrote : | #24 |
description: | updated |
Christophe Olinger (olingerc) wrote : | #25 |
- Screenshot.png Edit (271.9 KiB, image/png)
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.
Christophe Olinger (olingerc) wrote : | #26 |
Luca Livraghi (luca91) wrote : | #27 |
- Screenshot.jpg Edit (81.1 KiB, image/jpeg)
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) wrote : | #28 |
> 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/
input, textarea, checkbox, select, option {
background:#FFFFFF none no-repeat;
background-
background-color: #FFFFFF;
color: #000000;
}
button, input[type=button], input[type=submit], input[type=reset], input[type=file] {
background:#FFFFFF none no-repeat;
background-
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) wrote : | #29 |
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/
So the bug only appears in the FF3 beta.
Jose Hevia (jose-francisco-hevia) wrote : | #30 |
- Dark screen Edit (110.4 KiB, image/png)
I have a real problem here, if you want to reproduce this bug:
Download a dark theme:
http://
http://
http://
http://
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) wrote : Re: BadAn Firefox integration with dark themes | #31 |
- Screenshot-Gmail: Correo electrónico de Google - Mozilla Firefox 3 Beta 5.png Edit (140.5 KiB, image/png)
Another screenshot.
Changed in firefox-3.0: | |
status: | Incomplete → Confirmed |
Luca Livraghi (luca91) wrote : | #32 |
That's it, this is the bug.
All you can do, it's click to System-
John Vivirito (gnomefreak) wrote : | #33 |
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.
In Mozilla Bugzilla #70315, Alexander Sack (asac) wrote : | #34 |
Joe appears to be "gone"... flipping assignment to default again.
In Mozilla Bugzilla #70315, Alexander Sack (asac) wrote : | #35 |
not sure if its still the same bug, but linking ubuntu bug https:/
Alexander Sack (asac) wrote : | #36 |
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.
Changed in firefox-3.0: | |
importance: | Undecided → Medium |
status: | Confirmed → Triaged |
Changed in xulrunner: | |
status: | Unknown → Confirmed |
In Mozilla Bugzilla #437366, Phiw (phiw) wrote : | #37 |
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://
In Mozilla Bugzilla #437366, Phiw (phiw) wrote : | #38 |
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
In Mozilla Bugzilla #437366, Kliu (kliu) wrote : | #39 |
*** Bug 437392 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #437366, Kliu (kliu) wrote : | #40 |
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...
In Mozilla Bugzilla #437366, L. David Baron (dbaron) wrote : | #41 |
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.
In Mozilla Bugzilla #437366, user2037 (user2037) wrote : | #42 |
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.
In Mozilla Bugzilla #437366, Bzbarsky (bzbarsky) wrote : | #43 |
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.
In Mozilla Bugzilla #437366, Bzbarsky (bzbarsky) wrote : | #44 |
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.
In Mozilla Bugzilla #437366, Kliu (kliu) wrote : | #45 |
*** Bug 440319 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #437366, Kliu (kliu) wrote : | #46 |
*** Bug 423954 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #437366, Yehudab (yehudab) wrote : | #47 |
(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://
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.
In Mozilla Bugzilla #437366, Kliu (kliu) wrote : | #48 |
*** Bug 443612 has been marked as a duplicate of this bug. ***
Giuseppe Pennisi (giupenni78) wrote : | #49 |
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) wrote : | #50 |
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 !!
In Mozilla Bugzilla #437366, Phiw (phiw) wrote : | #51 |
*** Bug 450098 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #437366, Bzbarsky (bzbarsky) wrote : | #52 |
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?
In Mozilla Bugzilla #437366, Bzbarsky (bzbarsky) wrote : | #53 |
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.
In Mozilla Bugzilla #437366, L. David Baron (dbaron) wrote : | #54 |
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...
In Mozilla Bugzilla #437366, L. David Baron (dbaron) wrote : | #55 |
What about the following alternative:
Make nsPresContext:
if (!UseDocumentCo
return PR_FALSE;
Does that help?
In Mozilla Bugzilla #437366, Bzbarsky (bzbarsky) wrote : | #56 |
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.
In Mozilla Bugzilla #437366, L. David Baron (dbaron) wrote : | #57 |
What about removing the background bit from the bitmask in that case?
In Mozilla Bugzilla #437366, Bzbarsky (bzbarsky) wrote : | #58 |
That sounds much more promising. Lemme sleep on it and test the effect tomorrow.
In Mozilla Bugzilla #437366, Bzbarsky (bzbarsky) wrote : | #59 |
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.
In Mozilla Bugzilla #437366, Phiw (phiw) wrote : | #60 |
*** Bug 464262 has been marked as a duplicate of this bug. ***
In Mozilla Bugzilla #70315, Tchalvak (tchalvak) wrote : | #61 |
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.
In Mozilla Bugzilla #70315, Tchalvak (tchalvak) wrote : | #62 |
Hmmm, for whatever reason the project says seamonkey, so perhaps this is the wrong bug for the firefox issue in firefox 3.
Tchalvak (tchalvak) wrote : | #63 |
- darkDropdownsHaveDarkText.png Edit (11.5 KiB, image/png)
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?
In Mozilla Bugzilla #437366, Tchalvak (tchalvak) wrote : | #64 |
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://
With the bug:
https:/
Tchalvak (tchalvak) wrote : | #65 |
I added a more appropriate firefox/mozilla bug report to this launchpad entry:
https:/
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.
In Mozilla Bugzilla #437366, Tchalvak (tchalvak) wrote : | #66 |
Created attachment 352794
When using a dark system theme, Dark dropdowns have dark text, as per the images and bug filed on launchpad.
Changed in firefox: | |
status: | Unknown → Confirmed |
In Mozilla Bugzilla #437366, Tchalvak (tchalvak) wrote : | #67 |
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.
In Mozilla Bugzilla #437366, Bzbarsky (bzbarsky) wrote : | #68 |
Tchalvak, we know exactly why _this_ bug is happening. If you're seeing something other than this bug, please file a separate bug report.
In Mozilla Bugzilla #437366, L. David Baron (dbaron) wrote : | #69 |
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?)
In Mozilla Bugzilla #437366, Bzbarsky (bzbarsky) wrote : | #70 |
> 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.
In Mozilla Bugzilla #437366, Bzbarsky (bzbarsky) wrote : | #71 |
Pushed http://
In Mozilla Bugzilla #437366, L. David Baron (dbaron) wrote : | #72 |
(In reply to comment #27)
> Fixing what, exactly? The bug 58048 regression?
Yes.
It's also worth getting this into 1.9.1.
In Mozilla Bugzilla #437366, Bzbarsky (bzbarsky) wrote : | #73 |
I filed bug 471345 (and requested branch approvals for this patch).
Changed in firefox: | |
status: | Confirmed → Fix Released |
In Mozilla Bugzilla #437366, L. David Baron (dbaron) wrote : | #74 |
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.
In Mozilla Bugzilla #437366, Beltzner (beltzner) wrote : | #75 |
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.)
In Mozilla Bugzilla #437366, Bzbarsky (bzbarsky) wrote : | #76 |
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.
Changed in firefox: | |
status: | Fix Released → Confirmed |
In Mozilla Bugzilla #437366, Bzbarsky (bzbarsky) wrote : | #77 |
Created attachment 355502
Per comment 16
I did test that this works fine.
In Mozilla Bugzilla #437366, L. David Baron (dbaron) wrote : | #78 |
Comment on attachment 355502
Per comment 16
r+sr=dbaron
In Mozilla Bugzilla #437366, Bzbarsky (bzbarsky) wrote : | #79 |
In Mozilla Bugzilla #437366, Bzbarsky (bzbarsky) wrote : | #80 |
Comment on attachment 355502
Per comment 16
This should be a much safer fix than the other that we tried.
In Mozilla Bugzilla #437366, Beltzner (beltzner) wrote : | #81 |
Comment on attachment 355502
Per comment 16
a191=beltzner
In Mozilla Bugzilla #437366, Bzbarsky (bzbarsky) wrote : | #82 |
In Mozilla Bugzilla #437366, Samuel-sidler+old (samuel-sidler+old) wrote : | #83 |
Boris, does your patch apply to 1.9.0?
In Mozilla Bugzilla #437366, Bzbarsky (bzbarsky) wrote : | #84 |
Comment on attachment 355502
Per comment 16
Yes. I suppose we should take it there too.
Changed in firefox: | |
status: | Confirmed → Fix Released |
In Mozilla Bugzilla #437366, Dveditz (dveditz) wrote : | #85 |
Comment on attachment 355502
Per comment 16
Approved for 1.9.0.7, a=dveditz for release-drivers.
In Mozilla Bugzilla #437366, Bzbarsky (bzbarsky) wrote : | #86 |
Fixed on 1.9.0 branch.
CaptainInsaino (david-geraghty) wrote : | #87 |
I had the same problem. The following userContent.css file fixes it:
http://
It seems that the "-moz-appearance: none" lines are all important.
Musthafa Meeran (musthafameeran-deactivatedaccount) wrote : Re: [Bug 220263] Re: Bad Firefox integration with dark themes | #88 |
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://
> firefox-
>
> It seems that the "-moz-appearance: none" lines are all important.
>
> --
> Bad Firefox integration with dark themes
> https:/
> 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://
>
> In Firefox 3 I can't correct this problem.
>
Lutz (webmaster-phatsonic) wrote : | #89 |
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) wrote : | #90 |
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:/
> 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://
>
> In Firefox 3 I can't correct this problem.
>
In Mozilla Bugzilla #437366, Abillings (abillings) wrote : | #91 |
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/
In Mozilla Bugzilla #70315, Bstriker (bstriker) wrote : | #92 |
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
Changed in xulrunner: | |
importance: | Unknown → Medium |
Changed in firefox: | |
importance: | Unknown → High |
affects: | firefox-3.0 (Ubuntu) → firefox (Ubuntu) |
Changed in firefox (Ubuntu): | |
importance: | Medium → Low |
In Mozilla Bugzilla #70315, Krishna Kumar Deep (krishnakumardeep) wrote : | #93 |
Created attachment 811101
Bug70315Fx24.png
The bug is still present in Firefox(24.0).
In Mozilla Bugzilla #70315, Spyro-boy (spyro-boy) wrote : | #97 |
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.
In Mozilla Bugzilla #70315, Spyro-boy (spyro-boy) wrote : | #98 |
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.
In Mozilla Bugzilla #70315, Matei-tene-0 (matei-tene-0) wrote : | #99 |
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.
In Mozilla Bugzilla #70315, Matthew Hoener (ionsquare) wrote : | #100 |
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.
In Mozilla Bugzilla #70315, Matthew Hoener (ionsquare) wrote : | #101 |
For what it's worth, there is a very clean workaround in the ArchWiki:
https:/
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.
In Mozilla Bugzilla #70315, je-vv (je-vv) wrote : | #102 |
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/
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...
In Mozilla Bugzilla #70315, je-vv (je-vv) wrote : | #103 |
Though my problem is different though, the backgorund is white and the font is white as well
Luis Mondesi (lemsx1) wrote : | #94 |
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/
Essentially, going to pages like this https:/
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) wrote : | #95 |
- can't read Edit (125.1 KiB, image/png)
Example view from https:/
Anders Kaseorg (andersk) wrote : | #96 |
Firefox 47 worked around this by disabling the dark theme entirely.
Firefox 55 beta supports two new independent about:config settings, widget.
Official PPA for Firefox beta, if you don’t want to wait: https:/
In Mozilla Bugzilla #70315, Hewanci (hewanci) wrote : | #104 |
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-
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:/
https:/
https:/
https:/
https:/
https:/
https:/
https:/
https:/
https:/
https:/
https:/
https:/
https:/
https:/
https:/
In Mozilla Bugzilla #70315, Rimas-1 (rimas-1) wrote : | #105 |
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:/
3. On the other hand, form fields have always inherited the system-wide look by default. Mozilla even has it documented: https:/
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.
In Mozilla Bugzilla #70315, Hewanci (hewanci) wrote : | #106 |
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:/
> use#w_change-
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_
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...
In Mozilla Bugzilla #70315, Jason C. McDonald (codemouse92) wrote : | #107 |
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:/
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!
In Mozilla Bugzilla #70315, Qwerty Chouskie (asdfghrbljzmkd) wrote : | #108 |
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*
In Mozilla Bugzilla #70315, harry (vaaghoofdharry) wrote : | #109 |
Yeah pretty weird this is still an issue, should be pretty easy to fix. In the mean time. Meanwhile, this fixed my problem:
https:/
(backup your profile, then place the userContent.css file in your ~/.mozille/
In Mozilla Bugzilla #70315, Matei-tene-0 (matei-tene-0) wrote : | #110 |
(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:/
>
> (backup your profile, then place the userContent.css file in your
> ~/.mozille/
> doesn't exist)
This is a major improvement already and can also be used in Thunderbird.
The directory (on Ubuntu) is ~/.thunderbird/
Would like to see a built-in complete solution to this for both Firefox and Thunderbird.
In Mozilla Bugzilla #70315, Adomas-dev (adomas-dev) wrote : | #111 |
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:/
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!
In Mozilla Bugzilla #70315, killown (systemofdown) wrote : | #112 |
Still not fixed, what an annoying bug
In Mozilla Bugzilla #70315, Bruno Pagani (b-pagani) wrote : | #113 |
The best workaround I’ve found yet:
https:/
In Mozilla Bugzilla #70315, Bad-banana (bad-banana) wrote : | #114 |
bump!
i can't believe a small nuisance is taking 17 years not fixed.
In Mozilla Bugzilla #70315, L. David Baron (dbaron) wrote : | #115 |
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/
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
In Mozilla Bugzilla #70315, Evan Klitzke (eklitzke2) wrote : | #116 |
(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
Firefox apparently has some logic to ignore gtk-application
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:/
[2] https:/
In Mozilla Bugzilla #70315, Evan Klitzke (eklitzke2) wrote : | #117 |
I've got a patch up to try to mitigate the issue for GNOME 3.28 over at bug #1461538.
In Mozilla Bugzilla #70315, Jonathan Lane (jwlane) wrote : | #118 |
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.
In Mozilla Bugzilla #70315, Abhishek Madhu (abhishek.madhu) wrote : | #119 |
(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 :)]
In Mozilla Bugzilla #70315, Yuri Khan (yurivkhan) wrote : | #120 |
I predict that Apple is going to fix this bug in a few years, by evangelizing @media(
In Mozilla Bugzilla #70315, Pedro Côrte-Real (pedrocr) wrote : | #121 |
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.
In Mozilla Bugzilla #70315, Qwerty Chouskie (asdfghrbljzmkd) wrote : | #122 |
In the mean time, could `widget.
In Mozilla Bugzilla #70315, L. David Baron (dbaron) wrote : | #123 |
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.
In Mozilla Bugzilla #70315, Klingt-net+mozilla (klingt-net+mozilla) wrote : | #124 |
I use this extension as a workaround: [fix-dark-
In Mozilla Bugzilla #70315, Qwerty Chouskie (asdfghrbljzmkd) wrote : | #125 |
David: The problem here is point 2. Just setting `widget.
In Mozilla Bugzilla #70315, Benjamin Robinson (g-ben-j) wrote : | #126 |
If you uncheck "Use System Colors" it's no longer a problem.
In Mozilla Bugzilla #70315, Pedro Côrte-Real (pedrocr) wrote : | #127 |
I have "Use System Colors" unchecked, `widget.
In Mozilla Bugzilla #70315, L. David Baron (dbaron) wrote : | #128 |
re comment 57, with those settings (on Ubuntu 18.04), I see white text on a dark background.
In Mozilla Bugzilla #70315, Pedro Côrte-Real (pedrocr) wrote : | #129 |
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?
In Mozilla Bugzilla #70315, Stransky (stransky) wrote : | #130 |
System colors (and it's override) is covered by Bug 1422563
Dark Gtk theme is covered by Bug 1527048
In Mozilla Bugzilla #70315, Stransky (stransky) wrote : | #131 |
btw. widget.
In Mozilla Bugzilla #70315, Pedro Côrte-Real (pedrocr) wrote : | #132 |
I seem to have e10s enabled:
Multiprocess Windows 1/1 Enabled by default
and have set Adwaita:light:
widget.
I still get white text on white background on the Find textbox within webpages.
In Mozilla Bugzilla #70315, Pedro Côrte-Real (pedrocr) wrote : | #133 |
Here's a simple way to replicate this bug for me. In both cases I have the Light theme selected:
$ GTK_THEME=
(firefox runs and the Find box has white text on white background)
$ GTK_THEME=
(firefox runs and the Find box has the correct black text on white background)
Scott Palmer (skewty) wrote : | #134 |
- Screenshot from 2019-05-25 13-20-00.png Edit (50.3 KiB, image/png)
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.
widget.
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) wrote : | #135 |
For those that run linux and want to update their Firefox icon so it automatically launches with GTK_THEME=
$ cp /usr/share/
$ gedit ~/.local/
Change the "Exec=" line to read:
Exec=bash -c "GTK_THEME=
Save and Exit.
Now your Firefox icon should start using the Adwaita:light theme without a lingering terminal window.
In Mozilla Bugzilla #70315, Qwerty Chouskie (asdfghrbljzmkd) wrote : | #136 |
This should be fix as of https:/
Testing appreciated.
In Mozilla Bugzilla #70315, Asif Youssuff (yoasif) wrote : | #137 |
Can this be resolved fixed due to Bug 1527048 being fixed?
In Mozilla Bugzilla #70315, Stransky (stransky) wrote : | #138 |
Yes, duplicate of Bug 1527048.
*** This bug has been marked as a duplicate of bug 1527048 ***
Changed in xulrunner: | |
status: | Confirmed → Invalid |
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...