[Intel only] MacOS 13 (Ventura) editing is buggy due to keydown event not firing

[stevengharris]

The MarkupEditor handles keydown specially in markup.js for some specific cases:

• Enter when inside of a list or blockquote/indent and at the beginning or end of a styled paragraph
• Backspace/Delete when at the beginning of a styled paragraph
• Arrow keys (for specially handling near an image)
• Tab navigation in tables

The special handling deals with things like creating a new list item, moving between table cells, etc. When no special handling is required, the standard browser behavior happens, which is the case almost all of the time. As an example, when pressing Enter when the selection is in a list, we want to create a new list item of the same type as the list we are in. However, the standard browser behavior is just to insert a <br>, which is not what anyone expects and makes it impossible to add items to a list just by typing and pressing Enter at the end of each item.

On Mac Catalyst as of MacOS 13 (Ventura), we never receive a keydown event, so none of the special handling happens. As a result, only the standard (and as described above, incorrect) browser behavior occurs. As a result, from a user perspective, a lot of editing on Mac is buggy as of the Ventura release. Editing on iOS (as of iOS 16) works fine.

The problem is reproducible in the simplest app that uses a WKWebView. For example, using the following in your ContentView in a clean SwiftUI app created with Xcode will show the click event triggering, but the keydown event never triggers. Note:

• Both events trigger on iOS.
• Both events trigger on Mac Catalyst in MacOS 12.
• The input element has the same problem as the contenteditable div on Mac Catalyst on MacOS 13.

import SwiftUI
import WebKit

struct ContentView: View {
    var div: String = "<div contenteditable=\"true\" onkeydown=\"console.log('keydown: ' + event.key);\" onclick=\"console.log('click');\"<h1>Hello world.</h1></div>"
    var input: String = "<input type=\"text\" onkeydown=\"console.log('keydown: ' + event.key);\" onclick=\"console.log('click');\">"

    var body: some View {
        VStack {
            WebView(html: div)
            WebView(html: input)
        }
        .padding()
        .background(Color.red)
    }
}

struct WebView: UIViewRepresentable {
    
    var html: String
    
    func makeUIView(context: Context) -> WKWebView {
        return WKWebView()
    }
    
    func updateUIView(_ webView: WKWebView, context: Context) {
        webView.loadHTMLString(html, baseURL: nil)
    }
}

[stevengharris]

StackOverflow question: https://stackoverflow.com/q/74607757/8968411 (What kind of monster would downvote this question, come on!)

Simplified app demonstrating the issue: https://github.com/stevengharris/KeydownTest

Submitted as a Technical Support Incident to Apple...

PLATFORM AND VERSION
iOS
iMac 3.6 GHz 8-Core Intel Core i9
MacOS Ventura 13.1
Xcode 14.1

DESCRIPTION OF PROBLEM
I monitor keydown events in a contenteditable div displayed in a WKWebView to handle special cases like tab-based navigation and editing operations. The keydown is never triggered when running in Mac Catalyst starting with MacOS Ventura 13. It works fine in earlier MacOS releases. iOS targets work properly. Only Mac Catalyst on MacOS Ventura 13 has the problem.

STEPS TO REPRODUCE
A super-simple test case is provided at https://github.com/stevengharris/KeydownTest. This is a SwiftUI app with a single WKWebView set up in ContentView. The ContentView provides the HTML text for the WKWeb view, which contains a single contenteditable div that has onclick and onkeydown defined for it. Select the KeydownTestiOS target and deploy to My Mac (Mac Catalyst). Attach the Safari Web Inspector to the running app. As you click in the text, the console logs the word "click", because the click event is triggered. As you type text, your changes appear on the screen, but no logging shows up in the console, because no keydown events are received. Both events (the click and keydown) are received and log to the console when: 1) you deploy to an iOS device or simulator; 2) you deploy as a MacOS app (using the KeydownTestMac target); 3) you deploy on using Mac Catalyst on a machine with MacOS 12.6.

[stevengharris]

"Thank you for contacting Apple Developer Technical Support (DTS). We have reviewed your request and believe this issue would be best handled by the relevant engineering team directly, as it may require changes to the OS, tools, or the frameworks you are using."

Fun! Being tracked in FB11832366.

[stevengharris]

Per #82 (comment), the issue does not show up on an M1 running Ventura.

[stevengharris]

Yesterday Apple updated the Feedback to status "Potential fix identified - For a future OS update". The update says:

---

Please verify this issue with macOS 14 beta 5 and update your bug report with your results by logging into https://feedbackassistant.apple.com/ or by using the Feedback Assistant app.

macOS 14 beta 5 (23A5312d)
https://developer.apple.com/download/

If the issue persists, please attach a new sysdiagnose captured in the latest build and attach it to the bug report.

macOS sysdiagnose Instructions:
https://developer.apple.com/services-account/download?path=/OS_X/OS_X_Logs/sysdiagnose_Logging_Instructions.pdf

If this is no longer an issue you can close this feedback by selecting “Close Feedback” via the Actions button in Feedback Assistant.

[stevengharris]

Turns out macOS 14 beta 5 (23A5312d) pointed-to in the Feedback response is only available for Apple Silicon Macs, so I guess I won't be testing it yet.

[stevengharris]

I found I could install Beta 5 directly from Settings->General->Software Update and then install XCode 15 Beta 6. The issue is fixed in Sonoma as of Beta 5. Yay!!! I will leave this issue open until Sonoma releases, and after verifying the fix made it into production, I'll close this rambling issue and if necessary open one that still flags Ventura.

[stevengharris]

This issue is fixed in the MacOS Sonoma 14.0 release. I haven't checked if there might have been a backport to a Venture dot release, but closing the issue now.