[webkit-changes] [WebKit/WebKit] 33d14a: REGRESSION (266070 at main): iOS Notes: selection and...

[Wenson Hsieh]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 33d14a68bc4a80441096c71d70160a56bc21a760
      https://github.com/WebKit/WebKit/commit/33d14a68bc4a80441096c71d70160a56bc21a760
  Author: Wenson Hsieh <wenson_hsieh at apple.com>
  Date:   2023-10-13 (Fri, 13 Oct 2023)

  Changed paths:
    M Source/WebKit/Platform/spi/ios/UIKitSPI.h
    M Source/WebKit/Shared/EditorState.cpp
    M Source/WebKit/Shared/EditorState.h
    M Source/WebKit/Shared/EditorState.serialization.in
    M Source/WebKit/UIProcess/ios/WKContentView.mm
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.h
    M Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm
    M Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm
    M Tools/TestWebKitAPI/Tests/WebKitCocoa/SystemColors.mm

  Log Message:
  -----------
  REGRESSION (266070 at main): iOS Notes: selection and cursor color is gray in color and not yellow
https://bugs.webkit.org/show_bug.cgi?id=263123
rdar://116748932

Reviewed by Aditya Keerthi and Richard Robinson.

After the changes in <https://commits.webkit.org/266070@main>, the caret color from the page (i.e.
derived from either the CSS `caret-color` property or an explicitly-set `color` property) now
overrides any `tintColor` specified by the WebKit client (either directly on the view, or a global
application tint color). This means that in HTML Notes, which sets a CSS `color` attribute on the
body that's different from their app's yellow tint color, the selection is now gray (matching the
text color) instead of yellow.

To mitigate this and keep native apps with custom tint colors working with respect to CSS caret
colors without bringing back the double-caret observed on GitHub in https://webkit.org/b/259166, we
adjust our logic for determining the effective interaction tint color:

1.  If the page author's CSS specifies an explicit (non-auto) `caret-color`, use that.
2.  Otherwise, if the embedding app specifies a non-default tint color, use that.
3.  Otherwise, if the page author's CSS indirectly specifies a `caret-color` through an explicitly-
    set CSS `color` property, use that.
4.  Finally, fall back to the embedding app's tint color.

* Source/WebKit/Platform/spi/ios/UIKitSPI.h:

Remove now-unused SPI.

* Source/WebKit/Shared/EditorState.cpp:
(WebKit::operator<<):
* Source/WebKit/Shared/EditorState.h:
* Source/WebKit/Shared/EditorState.serialization.in:

Add a flag to indicate whether `caret-color: auto;` is used.

* Source/WebKit/UIProcess/ios/WKContentView.mm:
(-[WKContentView didMoveToWindow]):
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.h:
* Source/WebKit/UIProcess/ios/WKContentViewInteraction.mm:
(-[WKContentView setUpInteraction]):
(-[WKContentView cleanUpInteraction]):
(-[WKContentView _hasCustomTintColor]):

Add a helper method to compute whether or not the content view has a custom (non-default) tint
color. We deduce this by creating a new, unparented `UIView`, asking for its `tintColor`, and
comparing that against the content view's current tint color.

(-[WKContentView _cascadeInteractionTintColor]):

Implement the new fallback logic described above.

Drive-by fix: we can also replace usage of the `-_inheritedInteractionTintColor` SPI property with
just `-tintColor` instead. In UIKit, `-_inheritedInteractionTintColor` is implemented as another SPI
property, `-interactionTintColor`, which in turn simply wraps the API property `-tintColor`.

(-[WKContentView tintColorDidChange]):
* Source/WebKit/WebProcess/WebPage/ios/WebPageIOS.mm:
(WebKit::WebPage::getPlatformEditorState const):
* Tools/TestWebKitAPI/Tests/WebKitCocoa/SystemColors.mm:
(-[UIColor expectRed:green:blue:alpha:]):

Augment an existing API test to exercise these new scenarios.

Canonical link: https://commits.webkit.org/269314@main