| Summary: | Caret color in new text field should take background color and foreground color into consideration | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | WebKit | Reporter: | Adele Peterson <adele> | ||||||||
| Component: | Forms | Assignee: | Adele Peterson <adele> | ||||||||
| Status: | RESOLVED FIXED | ||||||||||
| Severity: | Normal | CC: | ian | ||||||||
| Priority: | P2 | ||||||||||
| Version: | 420+ | ||||||||||
| Hardware: | Mac | ||||||||||
| OS: | OS X 10.4 | ||||||||||
| Attachments: |
|
||||||||||
|
Description
Adele Peterson
2006-03-29 15:11:43 PST
Created attachment 7399 [details]
test
Created attachment 7401 [details]
patch
Comment on attachment 7401 [details]
patch
Hyatt and I talked about this. We may want to only do this for text fields... or just use the color of the rootEditableElement....or add a new css property -khtml-caret-color with good default values.
These are all text field regressions so they should all be P1. It's odd that text fields ever did this - rich text NSTextViews don't seem to. The old text fields didn't do this. Hyatt and I discussed adding this feature. Bumping back down to P2 since its not a regression. Changing title to reflect new goal. We want to choose a white or black caret based on the background color and foreground colors. Created attachment 11646 [details]
new patch
Hyatt and I discussed this new approach for this bug. This patch just gets the caret color from the root editable element. This will work well for text controls, and also will work for editable WebViews by just getting the color from the body element.
Comment on attachment 11646 [details]
new patch
r=me
Committed revision 17885 worldofwarcraft.com users, rejoice! |