Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

REGRESSION (266070@main): iOS Notes: selection and cursor color is gray in color and not yellow #19054

Merged
merged 1 commit into from
Oct 13, 2023

Conversation

whsieh
Copy link
Member

@whsieh whsieh commented Oct 13, 2023

33d14a6

REGRESSION (266070@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

a25fe67

Misc iOS, tvOS & watchOS macOS Linux Windows
✅ 🧪 style ✅ 🛠 ios ✅ 🛠 mac ❌ 🛠 wpe ✅ 🛠 wincairo
✅ 🧪 bindings ✅ 🛠 ios-sim ✅ 🛠 mac-AS-debug ❌ 🧪 wpe-wk2
✅ 🧪 webkitperl ✅ 🧪 ios-wk2 ✅ 🧪 api-mac ✅ 🛠 gtk
❌ 🧪 ios-wk2-wpt ✅ 🧪 mac-wk1 ✅ 🧪 gtk-wk2
✅ 🧪 api-ios 🧪 mac-wk2 ✅ 🧪 api-gtk
✅ 🛠 tv 🧪 mac-AS-debug-wk2
✅ 🛠 tv-sim
✅ 🛠 🧪 merge ✅ 🛠 watch
✅ 🛠 watch-sim

@whsieh whsieh requested a review from cdumez as a code owner October 13, 2023 16:55
@whsieh whsieh self-assigned this Oct 13, 2023
@whsieh whsieh added the Platform Portability improvements and other general platform improvements not driven directly by site bugs. label Oct 13, 2023
@webkit-ews-buildbot webkit-ews-buildbot added the merging-blocked Applied to prevent a change from being merged label Oct 13, 2023
@whsieh whsieh removed the merging-blocked Applied to prevent a change from being merged label Oct 13, 2023
@whsieh whsieh added the merge-queue Applied to send a pull request to merge-queue label Oct 13, 2023
@whsieh
Copy link
Member Author

whsieh commented Oct 13, 2023

Thanks for the reviews!

…ay 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
@webkit-commit-queue
Copy link
Collaborator

Committed 269314@main (33d14a6): https://commits.webkit.org/269314@main

Reviewed commits have been landed. Closing PR #19054 and removing active labels.

@webkit-commit-queue webkit-commit-queue merged commit 33d14a6 into WebKit:main Oct 13, 2023
@webkit-commit-queue webkit-commit-queue removed the merge-queue Applied to send a pull request to merge-queue label Oct 13, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Platform Portability improvements and other general platform improvements not driven directly by site bugs.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

7 participants