FWIW, there are quite a few things that haven't been added to the API, most importantly the ability to accept key events from pages where our content script isn't running.
In fact, very little has been added that has made our life easier (the main one being the search API) since we first started developing Tridactyl. Features have actually been taken away from us - notably the ability to operate on PDFs.
Not to detract from your point, though - most of the API was already there and fine in September 2017.
>FWIW, there are quite a few things that haven't been added to the API, most importantly the ability to accept key events from pages where our content script isn't running.
Speaking as an end-user, I find the eagerness with which web developers re-purpose key events to be extremely aggravating. If I hit ctrl-F, I want to use Firefox's native full page text search, not jump to the in-site search box.
I'd like to see Mozilla start treating key event capture as an opt-in-required permission like site notifications, location, camera, and microphone. Currently the only way to blanket-deny permission to capture key events is by disabling javascript. That's not ideal.
We have a thing in Tridactyl for this, actually ("blacklistkeys" if you're a user).
You roll your own by writing a userscript (e.g. Tampermonkey) that adds an event listener to keydown which runs key.cancelBubble = true and key.stopPropagation(). See line 343 https://github.com/tridactyl/tridactyl/blob/master/src/conte... (starts "leavegithubalone").
In fact, very little has been added that has made our life easier (the main one being the search API) since we first started developing Tridactyl. Features have actually been taken away from us - notably the ability to operate on PDFs.
Not to detract from your point, though - most of the API was already there and fine in September 2017.