Bug 313835 – REGRESSION (Safari 18.x): Copy main menu item is enabled with no selection in the web page

• Status: RESOLVED
• Resolution: FIXED
• Component: HTML Editing

[Jeff Johnson]

Created attachment 479420 [details]
Screenshot of the Clipboard Viewer app

Steps to reproduce:
1. Open https://example.org in Safari
2. Click in the web page to focus it
3. Open the Edit menu in the main menu bar

Expected results: The Copy menu item is disabled.

Actual results: The Copy menu item is enabled. Selecting the Copy menu item adds a useless com.apple.webarchive item to the pasteboard, which as far as I can tell can't actually be pasted anywhere. See the attached screenshot of the Clipboard Viewer app from Xcode Additional Tools.

This issue occurs in Safari, Safari Technology Preview, and other apps that use WebKit, such as Mail app and NetNewsWire.

I can reproduce the issue in Safari 18.6 on macOS 13.7.8 and later, including Safari 26 on macOS Tahoe. I can't reproduce the issue in Safari 17.6 on macOS 12.7.6.

[Radar WebKit Bug Importer]

<rdar://problem/176061974>

[Ryosuke Niwa]

This was an intentional change in https://commits.webkit.org/288559@main to allow copy in non-editable context.

[Jeff Johnson]

(In reply to Ryosuke Niwa from comment #2)
> This was an intentional change in https://commits.webkit.org/288559@main to
> allow copy in non-editable context.

It appears that the intention was just to fix the (deprecated) document.execCommand() API, but the change had an unfortunate side effect.

I don't think the logic for enabling the native platform Copy menu item in every WebKit-linked app should be determined by execCommand, which isn't even called by that menu item, and the Safari web archive added to the pasteboard is an oddity that doesn't seem intentional.

[Ryosuke Niwa]

(In reply to Jeff Johnson from comment #3)
>
> It appears that the intention was just to fix the (deprecated)
> document.execCommand() API, but the change had an unfortunate side effect.
> 
> I don't think the logic for enabling the native platform Copy menu item in
> every WebKit-linked app should be determined by execCommand, which isn't
> even called by that menu item, and the Safari web archive added to the
> pasteboard is an oddity that doesn't seem intentional.

No, this was very much the intended behavior change.

The point of https://commits.webkit.org/288559@main is to enable copy regardless of the selection state.
Either copying is enabled or not. We can't have it both ways.

[Jeff Johnson]

(In reply to Ryosuke Niwa from comment #4)
> 
> Either copying is enabled or not. We can't have it both ways.

With all due respect, this is not true. There's a crucial distinction between copy triggered by JavaScript and copy triggered by the native user interface.

The original bug report https://bugs.webkit.org/show_bug.cgi?id=156529 was not about native Mac main menu items but rather about HTML buttons. Many websites have a "Copy" button, and the buttons weren’t working in Safari like they were in other web browsers.

These HTML buttons have specific JavaScript code written for them with event listeners that will add relevant, sensical data to the clipboard when the button is clicked. Websites with such a button expect that this code will be triggered by the HTML button, not by the native main menu. The commit https://commits.webkit.org/288559@main provides relevant context to the copy event: “Take the focused element as clipboard event target.” When the button is clicked, that’s the context. Without a button, though, and without a selection either, a copy command has no context; it's meaningless. And the result, as we’ve seen, is that meaningless, irrelevant, nonsensical data gets added to the clipboard, a Safari web archive snippet that can’t even be pasted anywhere, because nothing accepts that type of data.

The logic for enabling native Mac menu items could and indeed should be distinct from the logic for enabling JavaScript copy. You can allow JavaScript copy without a selection while keeping the Mac menu items disabled in that situation. There’s a purpose in allowing HTML copy buttons to work, but there’s no purpose in enabling the main menu bar “Copy” command with no selection. Moreover, no web developers were even asking for that to happen, and certainly no native Mac developers or users were asking for that to happen.

[Tim Nguyen (:ntim)]

Pull request: https://github.com/WebKit/WebKit/pull/67821

[EWS]

Committed 316571@main (0b85f13185f5): <https://commits.webkit.org/316571@main>

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