Bug 297091 – [WPE] <dialog> does not close if "Escape" is pressed inside a "contenteditable" element

• Component: WPE WebKit
• Status: RESOLVED FIXED

[Yury Semikhatsky]

Steps to reproduce:
1. Open attached page
2. Put focus inside the contenteditable field
3. Press "Escape"

Expected:
The dialog is closed.

Actual:
The dialog stays open.

Works fine on GTK and other platforms.

Originally reported in Playwright: https://github.com/microsoft/playwright/issues/36727

[Yury Semikhatsky]

Created attachment 476302 [details]
test page

[Tim Nguyen (:ntim)]

*** Bug 297090 has been marked as a duplicate of this bug. ***

[Tim Nguyen (:ntim)]

*** Bug 297089 has been marked as a duplicate of this bug. ***

[Carlos Garcia Campos]

If this only happens in MiniBroweser this regressed in 298279@main because Escape is always claimed to be handled by MiniBrowser so the key event is not passed to webkit.

[Diego Pino]

(In reply to Carlos Garcia Campos from comment #4)
> If this only happens in MiniBroweser this regressed in 298279@main because
> Escape is always claimed to be handled by MiniBrowser so the key event is
> not passed to webkit.

I can reproduce the bug using 298278@main. On that build, I noticed I can close the dialog if I press "Ctrl + ESC" or "Shift + ESC". However, that doesn't work on 298279@main.

So there are two issues here. In one hand, 298279@main should not treat ESC as a WPE MiniBrowser shortcut, and let the WebProcessUI see that key stroke (I think replacing `return TRUE` for `return FALSE` in https://github.com/WebKit/WebKit/blob/main/Tools/MiniBrowser/wpe/main.cpp#L242 should fix that).

Then, there's the issue on why in WPE `WPE_KEY_Escape` is emitted only when Ctrl or Shit are pressed in combination with ESC.

[Yury Semikhatsky]

FWIW, Playwright 1.54.1 where the user reported the issue is shipped with WebKit https://commits.webkit.org/297047@main, which is a commit from July 7. So I don't think this is recently introduced bug.

[Diego Pino]

I figured out what is the issue.

When ESC key is pressed in WPE, they key is interpreted as "Cancel" because of https://github.com/WebKit/WebKit/blob/main/Source/WebKit/WebProcess/WebCoreSupport/wpe/WebEditorClientWPE.cpp#L108. On the other hand, in WebKitGTK, when ESC key is pressed the string returned is null.

The function call sequence is the following:

- Source/WebCore/page/EventHandler.cpp:internalKeyEvent
  - Source/WebCore/platform/libwpe/PlatformKeyboardEventLibWPE.cpp:disambiguateKeyDownEvent
  - Source/WebKit/WebProcess/WebCoreSupport/wpe/WebEditorClientWPE.cpp:handleKeyDown
    - Source/WebKit/WebProcess/WebCoreSupport/wpe/WebEditorClientWPE.cpp:interpretKeyEvent

Since `VK_ESCAPE` is a member of `keyDownEntries`, function `interpretKeyEvent` returns a value, and because of that `handleKeyDown` sets the event as `defaultHandled`. And since the keydown event was defaultHandled, `EventHandler` exists earlier here: https://github.com/WebKit/WebKit/blob/main/Source/WebCore/page/EventHandler.cpp#L4092

Removing VK_ESCAPE from keyDownEntries fixes the issue.

[Diego Pino]

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

[EWS]

Committed 298562@main (68ee5059655d): <https://commits.webkit.org/298562@main>

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