837529 - `tooltips` (only) fail to use "background-color:" style

Status: NEW

(Core :: CSS Parsing and Computation, defect)

Description

[DChil]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:18.0) Gecko/20100101 Firefox/18.0
Build ID: 20130116073211

Steps to reproduce:

in Firefox 18.0.1 and Thunderbird 17.0.2 on linux/64

setting a `tooltip` user style

	@namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);
	tooltip {
		color: yellow !important;
		background-color: blue !important;
	}




Actual results:

works -- changes *are* picked-up -- for `color` property, but NOT for `background-color`.

All tooltips are displayed with `color` == as defined in the styles, but `background-color` == BLACK.

styling `background-color` in other objects other than `tooltip` works fine; this insensitivity to `background-color` occurs ONLY in tooltips. 


Expected results:

tooltips should be displayed with `color` AND  `background-color` == as defined in the style.

Comment 1

[DChil]

bumped to Firefox 18.0.2;  issue continues, as reported

Comment 2

[Daniel Holbert [:dholbert]]

I can reproduce in latest nightly (using Stylish add-on to add the user style, and then visiting xkcd.com and checking the image hover text).

I can also reproduce this in a nightly from nearly 2 years ago:
  Mozilla/5.0 (X11; Linux x86_64; rv:2.2a1pre) Gecko/20110331 Firefox/4.2a1pre
so this isn't a regression (or not a recent one), FWIW.

Comment 3

[Daniel Holbert [:dholbert]]

I suspect (but am not 100% sure) that the background of this widget might be under GTK control.

You can, however, hack around this by styling ".tooltip-label" (the container inside the tooltip), instead of the tooltip itself.  This Stylish rule achieves what you're getting at in comment 0, in my nightly on Linux at least:

@namespace url(http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul);
tooltip {
  color: yellow !important;
  padding: 0px !important;
}
.tooltip-label {
  background: blue !important;
  padding: 4px !important;
}

Comment 4

[DChil]

I can confirm here that your "hack around" in #3 works perfectly in both FF 18.0.2 & TB 17.0.1.

Re:

> I can also reproduce this in a nightly from nearly 2 years ago

That's a bit surprising, as I can categorically state that my tooltips were styling just fine as recently as within the last month or so.

In any case, thanks for the workaround.

Comment 5

[Daniel Holbert [:dholbert]]

(In reply to DChil from comment #4)
> That's a bit surprising, as I can categorically state that my tooltips were
> styling just fine as recently as within the last month or so.

Ah, that's strange.  I wonder why I didn't see that.

In any case, if this does actually work for you in old builds, then the best path to getting it fixed would be for you to track down what day it broke in our development builds, using the "mozregression" tool:
 http://mozilla.github.com/mozregression/

You'll probably want to set up a firefox profile ahead of time, by running e.g.:

  mkdir ~/testing-profile
  firefox -no-remote -profile ~/testing-profile

...and then customize that profile to include your user style from comment 0.  (This way, you can re-use this profile across each of the mozregression tests, and you won't have to set up the stylesheet every time)

Then, you'd run mozregression like this (after you've installed it):

  mozregression --good=2012-02-01 -p $HOME/testing-profile

(2012-02-01 might seem like a long time ago, but it's better to err on the side of reaching-too-far-back-in-history.)

If you could do that and report back about the results, that'd be great!

Comment 6

[DChil]

I ran the regression as

  mozregression --good=2012-02-01 ...

and, ALL the builds displayed the reported problem.

???

Which runs contrary to what I recall experiencing, and suggests that there's another environmental component involved -- perhaps gtk, as you mentioned?

Comment 7

[Daniel Holbert [:dholbert]]

Could be, I suppose. Hard to say.

Given that nothing's broken recently here on the mozilla side (plus there's a workaround, plus it's a very niche use-case ;)), I think this is unlikely to be a high priority anytime soon -- but if you're interested in digging in further, and you find out any new information, definitely follow up here!

Comment 8

[Daniel Holbert [:dholbert]]

(to clarify:   s/nothing's broken/nothing has become broken/  -- that is, this isn't a recent regression)

Comment 9

[Barry Jackson]

I have recently been struggling with all tooltips in Firefox and Thunderbird displayed as black on black and could not change the black background.

I finally tracked it down to a KDE setting in systemsettings > application appearance > style > applications > widget style
...which was set to "gtk+ style"
Changing this to "Oxygen" fixed the problem and the background reverted to white.