Closed
Bug 176605
Opened 23 years ago
Closed 20 years ago
Use different typeaheadfind color when it's on a page with a similar background color
Categories
(SeaMonkey :: Find In Page, enhancement, P5)
SeaMonkey
Find In Page
Tracking
(Not tracked)
RESOLVED
FIXED
mozilla1.8beta2
People
(Reporter: aaronlev, Assigned: masayuki)
References
()
Details
(Keywords: access)
Right now we use a dark green highlight color for typeaheadfind searches. It
would be nice to have a second color choice when the web page's background is
similar to that. Would a yellow highlight would be a good second choice?
The peter pan fan page above is a good example where the color should change?
| Reporter | ||
Updated•23 years ago
|
Blocks: isearch
Severity: normal → enhancement
Keywords: access,
helpwanted
Priority: -- → P5
Summary: Used different typeaheadfind color when it's on a page with a similar background color → Use different typeaheadfind color when it's on a page with a similar background color
Target Milestone: --- → mozilla1.4alpha
Comment 1•23 years ago
|
||
Could we solve this selection for selection in general?
Also, should we be using the ::selection color defined in CSS if that's defined?
Comment 2•23 years ago
|
||
Um, as far as Type Ahead goes, the hex triplet is #38d878, yes? Perhaps using
the inverse of this -- #c72787 -- would work. The pink color would stand out
very well on the green page.
| Reporter | ||
Comment 3•23 years ago
|
||
We have nsTextFrame::EnsureDifferentColors(), which looks like it does what
Malachi suggests for the regular selection color, but only if the colors were
going to be exactly the same.
Boris, I think :selection should be used for the regular selection, but not for
typeaheadfind's. Or?
I wonder what would be a good algorith to see if 2 colors are "close"?
****
inline nscolor EnsureDifferentColors(nscolor colorA, nscolor colorB)
{
if (colorA == colorB)
{
nscolor res;
res = NS_RGB(NS_GET_R(colorA) ^ 0xff,
NS_GET_G(colorA) ^ 0xff,
NS_GET_B(colorA) ^ 0xff);
return res;
}
return colorA;
}
| Reporter | ||
Comment 4•23 years ago
|
||
I started playing around, and figuring out if a color is "close" is a lot harder
than I thought. Looking for a good algorithm.
The current algorithm that just tests if they're equal is totally lame. That
means it can be off by 1 and be considered different enough. No one can see the
difference!
Comment 5•23 years ago
|
||
As long as the R lies between 00 and C0, the G between 90 and FF, and B between
30 and b0, it seems too hard to tell between them... my code is rusty, but if
the triplet has components between those, you should maybe use the alternate.
| Reporter | ||
Comment 6•23 years ago
|
||
Right, but I want an algorithm that works no matter what 2 colors it's comparing.
Comment 7•23 years ago
|
||
For normal selections, this is bug 56314. In bug 56314 comment 6 I mentioned
that IE for Windows decides when to reverse selection colors based on the text
color rather than on the background color, possibly because many pages with
background images don't specify a background color.
Depends on: 56314
| Assignee | ||
Comment 8•20 years ago
|
||
fixed by the patch of bug 56314.
Assignee: aaronleventhal → masayuki
Keywords: helpwanted
| Assignee | ||
Comment 9•20 years ago
|
||
-> FIXED
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.4alpha → mozilla1.8beta2
Updated•17 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•