486425 - Findbar textbox for notfound is white-on-white

Status: VERIFIED FIXED

(Toolkit :: Find Toolbar, defect)

Description

[Phil Ringnalda (:philor)]

Bug 483378 removed the hacks that allowed for a red background-color in the findbar when the search fails, replacing it with a inset -moz-box-shadow, but then bug 476062 solved the fight between -moz-appearance and -moz-box-shadow by just dropping the box-shadow on the ground, so now ctrl+F, zzzzz just produces a white text on white background with white caret textbox (on Windows, not on Mac, haven't tried on Linux).

Comment 2

[Daniel Holbert [:dholbert]]

I see this on Linux, too:
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090401 Minefield/3.6a1pre

Platform --> All/All

Comment 3

[Boris Zbarsky [:bzbarsky]]

So why do we need to use box-shadow here at all?  Why not just set the background?

Comment 4

[Dão Gottwald [::dao]]

background doesn't work because the textbox is themed. It could be used after restoring the hack that bug 483378 removed, but then the focus ring would be missing again. The inset box-shadow allowed me to do exactly what we want: tinting the natively themed textbox.

Comment 5

[Boris Zbarsky [:bzbarsky]]

> background doesn't work because the textbox is themed

Setting the background color should drop the theming, though.  Or is the goal to have a background but not drop the theming?

Comment 6

[Boris Zbarsky [:bzbarsky]]

If so, does giving a background to the anonymous div inside the textbox work?

Comment 7

[Dão Gottwald [::dao]]

(In reply to comment #5)
> > background doesn't work because the textbox is themed
> 
> Setting the background color should drop the theming, though.

It doesn't in XUL.

> Or is the goal
> to have a background but not drop the theming?

Yes, we want to keep the native theming.

Comment 8

[Dão Gottwald [::dao]]

(In reply to comment #6)
> If so, does giving a background to the anonymous div inside the textbox work?

textbox > .textbox-input-box can be styled, but the textbox has a padding, so the inner box doesn't fill it. The padding could probably be removed and added to the inner box, but it would be better if we could just keep the default styling from textbox.css rather than duplicating slightly modified parts of it.

Comment 9

[Boris Zbarsky [:bzbarsky]]

> It doesn't in XUL.

Yes, but this is an HTML input.  At least assuming you really style the input and not the wholly-unrelated <xul:textbox>...  Or is it the latter that has the appearance styling?  If so, wouldn't it make sense to drop appearance on the XUL node and keep it on the actual input that really should have it?  Or am I missing something?

> but the textbox has a padding, so the inner box doesn't fill it

Are you talking about the <xul:textbox> having padding, here?  Given the style you suggested (which styles the html:input, not the anonymous div inside it), sounds like it.

Comment 10

[Dão Gottwald [::dao]]

(In reply to comment #9)
> > It doesn't in XUL.
> 
> Yes, but this is an HTML input.  At least assuming you really style the input
> and not the wholly-unrelated <xul:textbox>...  Or is it the latter that has the
> appearance styling?

Yes, the xul:textbox has the appearance.

> If so, wouldn't it make sense to drop appearance on the
> XUL node and keep it on the actual input that really should have it?  Or am I
> missing something?

Are you suggesting that we do that in general, or only for the find bar? I don't think we can do that in general, as we need to be able to put elements in the textbox that are contained in the textfield appearance. And I don't see how it would help with this bug -- the div inside of the html:input is surely not accessible from the find bar stylesheet.

> > but the textbox has a padding, so the inner box doesn't fill it
> 
> Are you talking about the <xul:textbox> having padding, here?  Given the style
> you suggested (which styles the html:input, not the anonymous div inside it),
> sounds like it.

Yes, the xul:textbox has padding.

This is the structure we're dealing with:

<xul:textbox class="findbar-textbox findbar-find-fast">
  <xul:hbox class="textbox-input-box" context="_child">
    <html:input class="textbox-input"/>
    <xul:menupopup class="textbox-contextmenu"/>
  </xul:hbox>
</xul:textbox>

Comment 11

[Boris Zbarsky [:bzbarsky]]

> Are you suggesting that we do that in general, or only for the find bar?

The latter, since the find bar is the case when we want the weird "native-looking control but in different colors please" behavior.

> the div inside of the html:input is surely not accessible from the find bar
> stylesheet

It's accessible from a UA stylesheet, though.  Though that does raise the issue of performance costs for all other documents that use html:input, of course...

I'm a little confused about how this used to work.  We were setting box-shadow on the <xul:textbox>, right?  How was that even showing up?  Wouldn't the <html:input> with its non-transparent background paint over it?

Comment 12

[Dão Gottwald [::dao]]

The html:input is transparent.

Comment 13

[Boris Zbarsky [:bzbarsky]]

Oh.  In that case, why are we worrying about any of this?  Why not just use a stack with a box under the HTML input that we turn red as desired?

Comment 14

[Dão Gottwald [::dao]]

A stack would be overkill, a container element would work -- see comment 8.

Comment 15

[Bill Gianopoulos [:WG9s]]

Attachment: workaround

This makes it red on white background, so it is at least visible.

Comment 16

[Bill Gianopoulos [:WG9s]]

Looks like there is an additional patch on bug 476062 up for review that addresses this issue.

Comment 21

[Bill Gianopoulos [:WG9s]]

Comment on attachment 370771 [details] [diff] [review]
workaround

A simpler workaround is to just add the following to userChrome.css:

.findbar-textbox[status="notfound"] {
  color: red !important;
}

Comment 22

[Dão Gottwald [::dao]]

Fixed by the latest patch in bug 476062. Thanks roc.

Comment 23

[Peter van der Woude [:Peter6]]

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090406 Minefield/3.6a1pre ID:20090406045355

VERIFIED/FIXED