[Webkit-unassigned] [Bug 253958] New: WKWebView should allow clients to opt in to "maintainsInactiveSelection" behavior

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=253958

            Bug ID: 253958
           Summary: WKWebView should allow clients to opt in to
                    "maintainsInactiveSelection" behavior
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: Unspecified
                OS: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit2
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: jalkut at red-sweater.com
                CC: kkinnunen at apple.com

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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230315/01ff0073/attachment-0001.htm>