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)

enhancement

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?
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
Could we solve this selection for selection in general? Also, should we be using the ::selection color defined in CSS if that's defined?
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.
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; }
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!
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.
Right, but I want an algorithm that works no matter what 2 colors it's comparing.
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
Component: Keyboard: Navigation → Keyboard: Find as you Type
fixed by the patch of bug 56314.
Assignee: aaronleventhal → masayuki
Keywords: helpwanted
-> FIXED
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Target Milestone: mozilla1.4alpha → mozilla1.8beta2
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.