Bug 285908 – REGRESSION(288559@main) [GTK] API test /WebKitGTK/TestWebViewEditor /webkit/WebKitWebView/cut-copy-paste/non-editable is failing

• Status: NEW
• Component: WebKitGTK

[Lauro Moura]

/webkit/WebKitWebView/cut-copy-paste/non-editable:                  FAIL
ERROR:/app/webkit/Tools/TestWebKitAPI/Tests/WebKitGtk/TestWebViewEditor.cpp:217:bool EditorTest::canExecuteEditingCommand(const char*): assertion failed (m_canExecuteEditingCommand == webkit_editor_state_is_copy_available(editorState())): (1 == 0)

Steps to reproduce:

./Tools/Scripts/run-gtk-tests --release --display-server=xvfb WebKitBuild/GTK/Release/bin/TestWebKitAPI/WebKitGTK/TestWebViewEditor

IIUC, 288559@main changed the copy behavior to take the focused element as the source if the context is not editable, per the spec https://www.w3.org/TR/clipboard-apis/#fire-a-clipboard-event.

From a slack discussion[1] about the failure while still in EWS:

> so line 217 is asserting that webkit_web_view_can_execute_editing_command and webkit_editor_state_is_copy_available yield the same result.
> You've changed the behavior of webkit_web_view_can_execute_editing_command without affecting the behavior of webkit_editor_state_is_copy_available so that's why the assertion is failing. 
> So we should ask GTK+ maintainers which behavior we should maintain. Either we want the new behavior of execCommand or the old behavior / webkit_editor_state_is_copy_available's.

webkit_web_view_can_execute_editing_command docs:

> Asynchronously check if it is possible to execute the given editing command.
> When the operation is finished, callback will be called. You can then call 

webkit_editor_state_is_copy_available docs:

> Gets whether a copy command can be issued.

[1] https://webkit.slack.com/archives/CU65R5WQY/p1736230230532089

[Carlos Alberto Lopez Perez]

This test is timing out (instead of failing) since bots were migrated to the new infra. See: https://bugs.webkit.org/show_bug.cgi?id=299598