Keyboard input is not taken away from underlying page, when editing

[Pascalio]

Bug Description

When editing your sticky note or marker tooltip, if the underlying page listens to keyboard shortcuts, it still gets those as you type.

How to reproduce

For example,

• go to a github page
• start editing the tab
• add a sticky note, or some marker highlight and click it to edit the tooltip
• type "s" and the github page will start the search bar.

Expected behaviour

When editing annotation text, the underlying page should be put at rest completely.

Additional information

When editing the HTML, the key associated with the shortcut simply doesn't respond.

[danny0838]

It's basically very difficult and somehow impossible to prevent the interaction of page scripts with the editor. A simpler workaround is to capture the page first and edit the captured version afterwards (assume that scripts are not captured).

HTML editing is a different mode and not comparable, and whether page scripts will act when editing mode is on is still dependent on the page scripts, not WSB.

[Pascalio]

I see. Unfortunately, I lack experience in Web development...
Worldbrain's Memex extension manages to edit its annotations without firing webpage shortcuts. Maybe it does so because it steals focus from the page? Or because the annotation is not "part" of the page but part of the lateral bar... Sorry, that's all the input I'm able to provide so far.

[danny0838]

Thank you for the information. Unfortunately the code of the extension are obfuscated and difficult to research.

It seems to have attached a higher priority event listener to be less likely interfered by page scripts, but still not impossible. A quick demonstration is to open a GitHub page, open the browser console and run the following code:

window.addEventListener('keydown', (event) => {
  console.warn(event);
  event.preventDefault();
  event.stopPropagation();
}, true);

And after this all hotkeys and inputs for the extension are all blocked.