Closed
Bug 486425
Opened 15 years ago
Closed 15 years ago
Findbar textbox for notfound is white-on-white
Categories
(Toolkit :: Find Toolbar, defect)
Toolkit
Find Toolbar
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?
Comment 2•15 years ago
|
||
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
![]() |
||
Comment 3•15 years ago
|
||
So why do we need to use box-shadow here at all? Why not just set the background?
Severity: normal → major
Comment 4•15 years ago
|
||
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•15 years ago
|
||
> 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•15 years ago
|
||
If so, does giving a background to the anonymous div inside the textbox work?
Comment 7•15 years ago
|
||
(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•15 years ago
|
||
(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•15 years ago
|
||
> 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•15 years ago
|
||
(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•15 years ago
|
||
> 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•15 years ago
|
||
The html:input is transparent.
![]() |
||
Comment 13•15 years ago
|
||
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•15 years ago
|
||
A stack would be overkill, a container element would work -- see comment 8.
Comment 15•15 years ago
|
||
This makes it red on white background, so it is at least visible.
Comment 16•15 years ago
|
||
Looks like there is an additional patch on bug 476062 up for review that addresses this issue.
Comment 21•15 years ago
|
||
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
Updated•15 years ago
|
Keywords: regression
Comment 22•15 years ago
|
||
Fixed by the latest patch in bug 476062. Thanks roc.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
Updated•15 years ago
|
Whiteboard: [fixed by bug 476062]
Target Milestone: --- → mozilla1.9.2a1
Comment 23•15 years ago
|
||
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
Reporter | ||
Updated•15 years ago
|
Flags: blocking1.9.2?
You need to log in
before you can comment on or make changes to this bug.
Description
•