onkeydown vs addEventListener

[0xE1]

Hi, thanks for extension :3

Now it's more of discussion rather than issue.

I've tested in stable chrome and canary, and for me this small snippet works like a charm: document.addEventListener("keydown", function(e){if (e.keyCode==8 && ['INPUT','TEXTAREA'].indexOf(e.target.tagName)==-1 && !e.target.isContentEditable){e.preventDefault();window.history.back();}}, false);

It's probably best to use this method if possible to prevent any places where document.onkeydown is used by someone else.

Also, have you thought about extending check functionality to see if possible forms are changed? Though it will severely increase complexity of extension which probably is not good and have a chance to not work as intended. Especially if there are hidden forms, or forms used in weird unintended ways...

Thanks, Anton

[oslego]

Thanks for using the extension.

I opted for onkeydown instead of addEventListener because I noticed the event listener route not to be consistently triggered. I've not found the root cause for it, but onkeydown works consistently so I'm not inclined to research further.

There's no issue with overwriting some other code in the page because Chrome extension content scripts work in what's called isolated worlds. That means they don't communicate directly with the JS on the page (they can by means of postMessage, but that's beyond the scope of this use case).

With regards to extra functionality, I'm not inclined to add that. It implies maintenance overhead and this extension is really created with the goal of reverting Chrome's decision to remove backspace as a way to navigate back. I'm hopeful that the public outcry will prompt Chrome developers to reintroduce the behavior, perhaps with a persistent chrome://flag or UI setting.