Closed Bug 486425 Opened 14 years ago Closed 14 years ago

Findbar textbox for notfound is white-on-white

Categories

(Toolkit :: Find Toolbar, defect)

defect
Not set
major

Tracking

()

VERIFIED FIXED
mozilla1.9.2a1

People

(Reporter: philor, Unassigned)

References

Details

(Keywords: regression, Whiteboard: [fixed by bug 476062])

Attachments

(1 obsolete file)

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).
Flags: blocking1.9.2?
Duplicate of this bug: 486426
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
OS: Windows XP → All
Hardware: x86 → All
So why do we need to use box-shadow here at all?  Why not just set the background?
Severity: normal → major
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.
> 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?
If so, does giving a background to the anonymous div inside the textbox work?
(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.
(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.
> 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.
(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>
> 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?
The html:input is transparent.
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?
A stack would be overkill, a container element would work -- see comment 8.
Attached patch workaround (obsolete) — Splinter Review
This makes it red on white background, so it is at least visible.
Looks like there is an additional patch on bug 476062 up for review that addresses this issue.
Duplicate of this bug: 486645
Duplicate of this bug: 486845
Duplicate of this bug: 486878
Duplicate of this bug: 486967
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;
}
Attachment #370771 - Attachment is obsolete: true
Keywords: regression
Fixed by the latest patch in bug 476062. Thanks roc.
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → FIXED
Whiteboard: [fixed by bug 476062]
Target Milestone: --- → mozilla1.9.2a1
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.2a1pre) Gecko/20090406 Minefield/3.6a1pre ID:20090406045355

VERIFIED/FIXED
Status: RESOLVED → VERIFIED
Flags: blocking1.9.2?
You need to log in before you can comment on or make changes to this bug.