Bug 207963

Summary: Expose caret color for clients
Product: WebKit Reporter: Megan Gardner <megan_gardner>
Component: New BugsAssignee: Megan Gardner <megan_gardner>
Status: RESOLVED FIXED    
Severity: Normal CC: commit-queue, simon.fraser, wenson_hsieh
Priority: P2 Keywords: InRadar
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
Patch
none
Patch
none
Patch
none
Patch
none
Patch for landing
none
Patch for landing none

Description Megan Gardner 2020-02-19 14:30:20 PST
Expose text insertion color for clients
Comment 1 Megan Gardner 2020-02-19 14:32:55 PST
Created attachment 391200 [details]
Patch
Comment 2 Megan Gardner 2020-02-19 14:33:58 PST
<rdar://problem/57383170>
Comment 3 Megan Gardner 2020-02-19 15:30:57 PST
Created attachment 391211 [details]
Patch
Comment 4 Megan Gardner 2020-02-19 15:39:30 PST
Created attachment 391212 [details]
Patch
Comment 5 Wenson Hsieh 2020-02-19 17:02:49 PST
Comment on attachment 391212 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=391212&action=review

> Source/WebKitLegacy/mac/WebView/WebFrame.mm:1624
> +    WebCore::Frame *frame = core(self);

Nit - * on the other side (I would also just use auto*)

> Source/WebKitLegacy/mac/WebView/WebFrame.mm:1633
> +    auto& renderer = *focusedElement->renderer();

What guarantees that the renderer exists?
Comment 6 Daniel Bates 2020-02-19 20:09:19 PST
Comment on attachment 391212 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=391212&action=review

This patch looks good.

> Source/WebKitLegacy/mac/WebView/WebFrame.mm:1622
> +- (CGColorRef)textInsertionColor

This is ok as-is. A better solution would be to name this caretColor and move this code nearer to -setCaretColor because:

1. This will now be the getter to the setter.
2. Because of (1) this enables use of muscle memory.

Actually as I am writing this I made the assumption that computeCaretColor could return the -setCaretColor. If this is true, ^^^ is true. If not, why not? If not, then I think the name should be underscore prefixed. If not, what would the return value mean in its most descriptive form? Could that be used as a more descriptive name for this function?

> Source/WebKitLegacy/mac/WebView/WebFrame.mm:1625
> +    auto* document = frame->document();

FYI frame can be nil

> Source/WebKitLegacy/mac/WebView/WebFrame.mm:1634
> +    return cachedCGColor(WebCore::CaretBase::computeCaretColor(renderer.style(), renderer.element()));

If computeCaretColor() returns an invalid color then what does cachedCGColor() return? Does it return nil? If so, then the optimal solution is to add a comment to explain this subtlety and do what you do now. If it does not then the optimal solution is to check if it's INVALID and return nil and otherwise do what you do now.
Comment 7 Megan Gardner 2020-02-20 09:57:50 PST
Created attachment 391297 [details]
Patch
Comment 8 Daniel Bates 2020-02-20 10:18:07 PST
Comment on attachment 391297 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=391297&action=review

> Source/WebKitLegacy/mac/WebView/WebFramePrivate.h:146
> +- (CGColorRef)getCaretColor;

This is ok as-is. The optimal solution would be to define @property caretColor because:

1. Can remove -setCaretColor.
2. No need to add -getCaretColor
3. Because of (2) no need to rename -getCaretColor to -caretColor to conform to WebKit Code Style guide.
Comment 9 Daniel Bates 2020-02-20 10:53:36 PST
Comment on attachment 391297 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=391297&action=review

> Source/WebKitLegacy/mac/WebView/WebFrame.mm:1449
> +    auto color = WebCore::CaretBase::computeCaretColor(renderer->style(), renderer->element());

Is it OK if renderer->element() != focusedElement? If so, why? Contrived example: image maps.
Comment 10 Megan Gardner 2020-02-20 11:27:37 PST
Created attachment 391312 [details]
Patch for landing
Comment 11 Simon Fraser (smfr) 2020-02-20 13:03:15 PST
Comment on attachment 391312 [details]
Patch for landing

View in context: https://bugs.webkit.org/attachment.cgi?id=391312&action=review

> Source/WebKitLegacy/mac/WebView/WebFramePrivate.h:145
> +@property (nonatomic, readwrite) CGColorRef caretColor;

readwrite? Is it supposed to be settable?
Comment 12 Megan Gardner 2020-02-20 13:04:18 PST
Comment on attachment 391312 [details]
Patch for landing

View in context: https://bugs.webkit.org/attachment.cgi?id=391312&action=review

>> Source/WebKitLegacy/mac/WebView/WebFramePrivate.h:145
>> +@property (nonatomic, readwrite) CGColorRef caretColor;
> 
> readwrite? Is it supposed to be settable?

yep, this replaces the setter above and adds a getter.
Comment 13 Simon Fraser (smfr) 2020-02-20 13:06:14 PST
Comment on attachment 391312 [details]
Patch for landing

View in context: https://bugs.webkit.org/attachment.cgi?id=391312&action=review

> Source/WebKitLegacy/mac/WebView/WebFrame.mm:1435
> +- (CGColorRef)caretColor

This doesn't return a retained color (and there's no autorelease for CF objects), so I'm a bit concerned about the lifetime of the CGColorRef. If WebCore decided to purge it from the cache, the client's color would be deleted.

>> Source/WebKitLegacy/mac/WebView/WebFramePrivate.h:145
>> +@property (nonatomic, readwrite) CGColorRef caretColor;
> 
> readwrite? Is it supposed to be settable?

Oh I see that's old behavior.
Comment 14 Megan Gardner 2020-02-20 14:41:30 PST
Created attachment 391336 [details]
Patch for landing
Comment 15 WebKit Commit Bot 2020-02-20 15:16:35 PST
Comment on attachment 391336 [details]
Patch for landing

Clearing flags on attachment: 391336

Committed r257097: <https://trac.webkit.org/changeset/257097>
Comment 16 WebKit Commit Bot 2020-02-20 15:16:36 PST
All reviewed patches have been landed.  Closing bug.