Closed
Bug 176605
Opened 22 years ago
Closed 19 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•22 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•22 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•22 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•22 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•22 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•22 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•22 years ago
|
||
Right, but I want an algorithm that works no matter what 2 colors it's comparing.
Comment 7•22 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•19 years ago
|
||
fixed by the patch of bug 56314.
Assignee: aaronleventhal → masayuki
Keywords: helpwanted
Assignee | ||
Comment 9•19 years ago
|
||
-> FIXED
Status: NEW → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.4alpha → mozilla1.8beta2
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•