electron: webview no longer emits keyboard events
Sorry if this is a duplicate. I searched and searched and I didn’t find something quite the same, but it is similar and probably related to https://github.com/electron/electron/issues/14255 and a few other tickets all reporting broken events (all the tickets I found are different classes of events, none specific to key events) since OOPIF.
I’m also not certain if this is intended behavior with OOPIF.
- Output of
node_modules/.bin/electron --version:v3.0.2 - Operating System (Platform and Version):
$ uname -a
Linux lyra 4.18.10-arch1-1-ARCH #1 SMP PREEMPT Wed Sep 26 09:48:22 UTC 2018 x86_64 GNU/Linux
- Output of
node_modules/.bin/electron --versionon last known working Electron version (if applicable):v3.0.0-beta.5
Expected Behavior
keydown keypress, etc events are emitted when a webview is focused.
Actual behavior No such events are emitted.
To Reproduce Please see https://github.com/cprussin/electron-webview-key-event-bug, specifically the commit https://github.com/cprussin/electron-webview-key-event-bug/commit/1cec1ec745331f272b6b3b0ee26446686cc28900. Clone the repo and run the typical setup commands:
$ git clone https://github.com/cprussin/electron-webview-key-event-bug.git
$ cd electron-webview-key-event-bug
$ yarn
$ npx electron .
Note that when you press any keys, you get an alert indicating what key you pressed. Then, focus the webview and note that no longer do the alerts show. Note that there’s a key down listener attached to both the webview itself, and the document element of the frame.
Additional Information
Everything inside the webview still works properly–e.g., if I add listeners to the document element in a preload script, they are fired properly.
EDIT: I did further testing, and I’ve noticed that the before-input-event event on the webContents instance for the window containing the webview is also not fired. Not that this is particularly unexpected, just figured it might be interesting or helpful.
EDIT 2: after more testing, this appears to work up to 3.0.0-beta.5, as with the related bug I linked (https://github.com/electron/electron/issues/14255) I’ve updated the header to this ticket accordingly.
About this issue
- Original URL
- State: closed
- Created 6 years ago
- Reactions: 2
- Comments: 20 (4 by maintainers)
Commits related to this issue
- Downrev electron due to https://github.com/electron/electron/issues/14905 — committed to cprussin/minichrome by cprussin 6 years ago
I’m not here to throw any accusations. I respect that the work being done here is done freely and in the developers’ own time. And I can understand that things might be prioritized by the needs of the core team focused on electron.
I’m just hoping that there’s some room to push back on this just being a loss of functionality, or to find the right medium for discussing.
Agreed with @mhuggins --additionally there are folks such as myself that would be willing to invest some time in working on a fix, assuming it truly is a bug and given some pointers about what the right fix would be and the source of the fundamental issue (e.g., is proxying the event via the IPC truly impossible, or is it the wrong approach; if the latter, what would be the right approach?).
@codebytere couldn’t this be fixed similar to #14255, by proxying the event through the IPC?
See https://github.com/electron/electron/pull/14344
Unfortunately, this is intended behavior with
OOPIF, and won’t be possible for us to fix 😦Should it become possible someday, we’ll work to implement it!
I think it’s more like they don’t care and don’t want to spend time with this because it is not their problem. “won’t be possible for us to fix”. This means exactly this.
Everything is possible, everything can be fixed, there is always a way. As a last resort they could commit to Chromium upstream to have some API or whatever.
Hi,
I have the same/similar issue, I have a repo here which demonstrates it: https://github.com/Levente0xFFFF/electron-quick-start
If I write
instead of
then it works fine.
Also
works fine.