@deepak1556 I did look into making a spec but we currently have no way to trigger keyboard inputs that map into the HandleKeyboardEvent method (we skip them and go straight to ForwardKeyboardEvent.

webContents.sendInputEvent should work, maybe create an internal event that gets emitted from HandleKeyboardEvent and check if it receives right shortcuts for devtools with something like the following.

await emitOnce('devtools-focused', mainWindow.webContents)
mainWindow.devToolsWebContents.sendInputEvent({
    type: 'keyDown',
    modifiers: ['command'],
    keyCode: 'V'
})

@deepak1556 I thought sendInputEvent skipped this stuff, will give it a shot 👍

@deepak1556 Test added 👍

@deepak1556 The test was failing on CI and it was super flaky locally, ended up using the robotjs npm module to fake a paste keypress at the OS level and see if the app responds correctly. IMO it's a better test anyway 👍

Why is it required to test the specific shortcut execution ? Wouldn't it be enough to just see if the shortcut gets passed to the desired window in HandleKeyboardEvent ? The specs could be simpler in that case.

@deepak1556 I don't want to emit an event purely for the case of testing, people will start using it when they shouldn't and making this spec isn't too hard and is guaruntee'ed end-to-end working 👍

I don't want to emit an event purely for the case of testing, people will start using it when they shouldn't

We already have a couple of internal events, methods purely for testing. Agreed this could be easier if we have native tests. Incase we want to go with the non event route then a shortcut thats deterministic like devtools reload, I am just worried about the polling for checking the clipboard response, it can get flaky on ci.

I am good with the original fix for the issue and the spec looks good too, was just hoping it could be better.

I am just worried about the polling for checking the clipboard response, it can get flaky on ci.

To be honest, I added that even though it was working synchronously consistently. I added it with the specific intent of avoiding future race condition flakes. I think this is in a relatively good state.

I've disabled these tests on CI on macOS, assuming the VM's don't work with robotjs or something. The tests pass locally on macOS on both my macOS machines and someone else's.

Failed windows ia32 CI was a flake

Release Notes Persisted

fix basic shortcuts (copy, paste, etc.) not working in devtools

/trop run backport-to 3-0-x

The backport process for this PR has been manually initiated,
sending your 1's and 0's to "3-0-x" here we go! :D

Does this have any relation to #14905 & #14883?

@mhuggins no