macOS: web view not handling keyboard shortcuts (Issue #23151)
Tobias Taschner
Description
When pressing standard keyboard shortcuts like Cmd+Q inside a web view they are simply ignored.
Cmd+C/V/X/A are specifically handled via performKeyEquivalent: inside the web view implementation.
I first thought this is a general issue with WKWebView but I've created a minimal macOS app without wxWidgets and this doesn't happen. Also Cmd+C/V/X/A just work without an extra implementation like in the wxWebView implementation.
I've tried tracing the further into wxWidgets keyboard event handling, but I just found that wxWidgetCocoaImpl::keyEvent() isn't called for Cmd key combinations inside a wxWebView as the are for other key combinations.
To Reproduce:
- Open the webview sample
- Click on the web view
- Press Cmd+Q (nothing happens)
- Click on the address bar
- Press Cmd+Q (application quits as expected)
Platform and version information
- wxWidgets version 3.3.0
- wxWidgets port wxOSX
- OS macOS 12
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Tobias Taschner
@csomor Maybe you have an idea on this issue and could point me in the right direction?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Stefan Csomor
@TcT2k wxWidgetCocoaImpl::doCommandBySelector gets called with a selector 'noop:', so I'll override things on the webview level, and make a PR, for you to test what else gets broken with this attempt ....
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Tobias Taschner
Thanks for looking into this. Cmd+Q works for me with your changes and should be merged.
Apart from that could it be that Cmd+C/V/X/A don't work without my performKeyEquivalent implementation because wxWidgets apps lack the default Edit menu that includes these shortcuts?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Stefan Csomor
Thanks for looking into this. Cmd+Q works for me with your changes and should be merged.
The Cmd-Q i was able to test, but I fear that this change might have otherwise unwanted consequences, that's why I'd be grateful if you could test things thoroughly
Apart from that could it be that Cmd+C/V/X/A don't work without my
performKeyEquivalentimplementation because wxWidgets apps lack the defaultEditmenu that includes these shortcuts?
yes, because the webview sample lacks a proper edit menu (with the proper default IDs)
wxMenu *editMenu = new wxMenu;
editMenu->Append(wxID_UNDO);
editMenu->Append(wxID_REDO);
editMenu->AppendSeparator();
editMenu->Append(wxID_CUT);
editMenu->Append(wxID_COPY);
editMenu->Append(wxID_PASTE);
editMenu->AppendSeparator();
editMenu->Append(wxID_SELECTALL);
menuBar->Append(editMenu, "&Edit");
as soon as you add this you don't need performKeyEquivalent and the menu items get enabled/disabled automatically
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Tobias Taschner
I've tested a little more and overall I can still say that Cmd+Q works. But I'm a little confused on the why.
The difference simply seems to be that as soon as doCommandBySelector: is implemented the Cmd+Q seems to be handled correctly. The important thing seems to be that the super implementation isn't called.
The call stack seems quite different in when doCommandBySelector: is implemented in wxWKWebView or whether doCommandBySelector: in wxNSView is called.
</details>
<details>
<summary>With implementation</summary>
Thread 1 Queue : com.apple.main-thread (serial)
#0 0x0000000102e11ef4 in -[WXWKWebView doCommandBySelector:] at /Users/user/Development/OpenSource/wxWidgets/src/osx/webview_webkit.mm:660
#1 0x00000001b48c9f8c in -[NSKeyBindingManager(NSKeyBindingManager_MultiClients) interpretEventAsCommand:forClient:] ()
#2 0x00000001b4a2edc8 in -[NSKeyBindingManager(NSKeyBindingManager_MultiClients) interpretKeyEvents:forClient:] ()
#3 0x00000001b48c8778 in -[NSView interpretKeyEvents:] ()
#4 0x00000001d0599844 in WebKit::WebViewImpl::collectKeyboardLayoutCommandsForEvent(NSEvent*) ()
#5 0x00000001d0599afc in WebKit::WebViewImpl::interpretKeyEvent(NSEvent*, void (bool, WTF::Vector<WebCore::KeypressCommand, 0ul, WTF::CrashOnOverflow, 16ul, WTF::FastMalloc> const&) block_pointer) ()
#6 0x00000001d059b300 in WebKit::WebViewImpl::performKeyEquivalent(NSEvent*) ()
#7 0x00000001b49b6668 in -[NSView performKeyEquivalent:] ()
#8 0x00000001b49b6668 in -[NSView performKeyEquivalent:] ()
#9 0x00000001b4f65a98 in -[NSWindow _commonPerformKeyEquivalent:conditionally:] ()
#10 0x00000001b4e2e0f4 in routeKeyEquivalent ()
#11 0x00000001b482ce6c in -[NSApplication(NSEvent) sendEvent:] ()
#12 0x0000000103390498 in -[wxNSApplication sendEvent:] at /Users/user/Development/OpenSource/wxWidgets/src/osx/cocoa/utils.mm:359
#13 0x00000001b4ae70f4 in -[NSApplication _handleEvent:] ()
#14 0x00000001b46af008 in -[NSApplication run] ()
#15 0x0000000103355cac in wxGUIEventLoop::OSXDoRun() at /Users/user/Development/OpenSource/wxWidgets/src/osx/cocoa/evtloop.mm:301
#16 0x000000010607187c in wxCFEventLoop::DoRun() at /Users/user/Development/OpenSource/wxWidgets/src/osx/core/evtloop_cf.cpp:326
#17 0x0000000105f3cc08 in wxEventLoopBase::Run() at /Users/user/Development/OpenSource/wxWidgets/src/common/evtloopcmn.cpp:87
#18 0x0000000105ed56fc in wxAppConsoleBase::MainLoop() at /Users/user/Development/OpenSource/wxWidgets/src/common/appbase.cpp:347
#19 0x0000000105ed5204 in wxAppConsoleBase::OnRun() at /Users/user/Development/OpenSource/wxWidgets/src/common/appbase.cpp:269
#20 0x0000000102eab420 in wxAppBase::OnRun() at /Users/user/Development/OpenSource/wxWidgets/src/common/appcmn.cpp:334
#21 0x00000001032e73fc in wxApp::OnRun() at /Users/user/Development/OpenSource/wxWidgets/src/osx/carbon/app.cpp:356
#22 0x0000000105f99814 in wxEntry(int&, wchar_t**) at /Users/user/Development/OpenSource/wxWidgets/src/common/init.cpp:490
#23 0x0000000105f999dc in wxEntry(int&, char**) at /Users/user/Development/OpenSource/wxWidgets/src/common/init.cpp:500
#24 0x0000000102806b50 in main at /Users/user/Development/OpenSource/wxWidgets/samples/webview/webview.cpp:297
#25 0x0000000102bf508c in start ()
</details>
I'm really if this is an issue, but I found in interesting.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Stefan Csomor
If WKWebView(WKInternalMac) _web_superDoCommandBySelector is called, then somehow the default menu-keyshortcut handling of wx is not used, as if it assumes no-one is interested ? I don't know, but if we override, then wx itself is getting the key-shortcut properly via NSMenu performKeyEquivalent -> wxNSMenuItem clickedAction:
@vadz is it ok if I merge this now or would you rather wait until after 3.2.2 ?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
It seems like this fixes a user-visible problem, so it would be better to include it in 3.2.2. I don't think this can break anything outside of wxWebView, can it?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
VZ
Closed #23151 as completed via bf9076e.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Stefan Csomor
I don't think this can break anything outside of
wxWebView, can it?
No, it's really isolated for wxWebView
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Tobias Taschner
@csomor I've just discovered there are unintended consequences of the fix. Backspace and cursor keys don't work inside a text input inside a website. Give it a try in the webview sample and the searchbox of the wxWidgets website. doCommandBySelector: does get calls for these keys. The cursor keys DO work for scrolling outside a text input.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Stefan Csomor
@TcT2k Thanks Tobias for the thorough testing, I feared we might run into something like this, how about extending the doCommandBySelector a little bit to:
if (aSelector != @selector(noop:))
[super doCommandBySelector:aSelector];
else if (impl)
impl->doCommandBySelector(aSelector, self, _cmd);
in my tests now the quit is still triggered correctly, while arrow keys et al are still working ...
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.
Tobias Taschner
I've tried your proposal and it seems to work as described. Enabling all navigation inside a text field and functional Cmd+Q.
The only still thing I found which still is a difference between wxWebView and a wxTextCtrl is that an accelerator that's just a function key (e.g. F5) doesn't work in wxWebView(regardless of inside a text or not). Other accelerators like Cmd+R do work. I don't think it's that important as function key accelerators in macOS are rare, but maybe you have an idea.
Otherwise please commit your fix and it should also be included in 3.2.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you are subscribed to this thread.