WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
NEW
253958
WKWebView should allow clients to opt in to "maintainsInactiveSelection" behavior
https://bugs.webkit.org/show_bug.cgi?id=253958
Summary
WKWebView should allow clients to opt in to "maintainsInactiveSelection" beha...
Daniel Jalkut
Reported
2023-03-15 07:11:19 PDT
WKWebView, by way of WebViewImpl.mm and WebPageProxy.cpp, has a default behavior to clear the user selection when resigning first responder. This has had unfortunate effects that have been mitigated over the years by various amendments, for example to prevent losing selection when presenting a sheet (
https://bugs.webkit.org/show_bug.cgi?id=244742
), and to prevent losing selection when using the web inspector (
https://bugs.webkit.org/show_bug.cgi?id=59721
). Unfortunately, there remain unfortunate effects in both Apple's and 3rd party clients, where the expected behavior would match NSTextView's default selection preservation, but instead the selection is cleared. Two examples are Apple's Mail.app, and my MarsEdit (
https://redsweater.com/marsedit
), each of which uses WKWebView to provide a rich text editor for composing HTML. By virtue of being embedded in a window alongside other controls which can gain focus, selections that are made in either of Mail's or MarsEdit's rich text areas get lost when tabbing to or clicking on other UI components in the window. Even a simple task such as invoking the inline find bar, which is meant to feel to the user as an ephemeral process that barely disturbs the editing process, results in the selection being lost. For example: 1. Open Mail.app 2. Click into the body editor 3. Type "This is a test" 4. Double click "test" to select it 5. Press Cmd-F to invoke the inline find bar 6. Press ESC to dismiss the find bar RESULT: the selection of "test" is lost, leaving the user to find it again and re-select it to pick up where they were. The same issue, and issues like it, affect my app, and undoubtedly others. It all begs the question: who benefits from the default behavior? If nobody, can we change the behavior so that, instead of painstakingly opting certain clients out of the behavior, we opt everybody in? If some clients do benefit from the default behavior, it would be good to provide a mechanism by which 3rd party apps, as well as Apple's apps such as Mail, can opt out of the behavior. Currently there is a private SPI on WKPage (WKPageSetMaintainsInactiveSelection) to opt out of it, but apps that used this would risk rejection by App Store review, and by virtue of it being in the C++ layer of WebKit, it would be harder for a typical Cocoa app to invoke, in any case. In short: let's consider making `maintainsInactiveSelection` the default assumption for WKWebView clients, and if that is deemed too dangerous, or not pragmatic, let's provide a public-facing mechanism for clients to opt out of Safari's default behavior of clearing the selection when resigning key. Note: I'm writing a new bug to cover this in spite of the existence of a tangential bug at
https://bugs.webkit.org/show_bug.cgi?id=26870
, because that bug pertains specifically to a change requested for the legacy WebView API. I think there are broader implications of the root issues for this bug which a new ticket would be better-suited to collecting.
Attachments
Add attachment
proposed patch, testcase, etc.
Radar WebKit Bug Importer
Comment 1
2023-03-22 07:12:16 PDT
<
rdar://problem/107053621
>
Note
You need to
log in
before you can comment on or make changes to this bug.
Top of Page
Format For Printing
XML
Clone This Bug