-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
whsieh
added
the
Platform
Portability improvements and other general platform improvements not driven directly by site bugs.
label
Oct 13, 2023
EWS run on previous version of this PR (hash eac2ec0) |
whsieh
requested review from
hortont424,
pxlcoder,
rr-codes,
aprotyas and
megangardner
October 13, 2023 16:55
rr-codes
approved these changes
Oct 13, 2023
pxlcoder
approved these changes
Oct 13, 2023
webkit-ews-buildbot
added
the
merging-blocked
Applied to prevent a change from being merged
label
Oct 13, 2023
EWS run on current version of this PR (hash a25fe67)
|
aprotyas
approved these changes
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
force-pushed
the
eng/263123
branch
from
October 13, 2023 19:27
a25fe67
to
33d14a6
Compare
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
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.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
33d14a6
a25fe67
🧪 mac-wk2🧪 mac-AS-debug-wk2