Awaiting a promise before returning it doesn't make sense if the await
isn't in a try/catch as awaiting forces a function to be async and thus
turns its return value and any error it might throw into a promise.
Worse than that, it can result in an unnecessary context switch which
could be bad for performance.
The previous code simulated an input event in order to trigger the input
event handler which recomputed completions. This was ok until delays
were added to the input event handlers in order to reduce the lag that
could happen when typing fast/keeping a key pressed. This delay also
affects completion computation on other actions, such as fillcmdline.
In order to remove this delay, we move completion computation out of the
event handler and directly call this functions everywhere we previously
triggered an input event.
This should help with https://github.com/tridactyl/tridactyl/issues/1242
commandline_background.ts:history() isn't used anywhere and is wrong (it
doesn't respect the historyresults setting) so this commit removes it.
Also, currentWindowTabs and allWindowTabs are both used in a single
place (respectively Tab and TabAll completions) and do not perform anything
complicated, thus it's better to have completions juste use browserBg
instead of manually messaging the background process.
Using performance.now() was a pretty dumb idea that didn't completely
protect us against race conditions and I don't know why I did that
instead of the new code in this commit, which does completely protect us
against race conditions.
Issue #1237 is caused by multiple content scripts being inserted in the
page. According to https://bugzilla.mozilla.org/show_bug.cgi?id=1491994
, declarations might be shared between inserted content scripts. This
means that we can implement a lock that the first content script would
grab and that would make the others fail to load entirely.
https://github.com/tridactyl/tridactyl/issues/1237 is caused by multiple
command lines being instantiated in the tab. All command lines receive
the "fillcmdline tabopen" message, only one receives the key events
generated by typing stuff in the command line and then they all receive
the "ex.accept_line" message.
There can be two causes ; either Firefox loads multiple Tridactyls
(unlikely) or we load multiple commandlines (more likely). Moving
command line creation out of init() should fix this as the worst that
can happen now when init() is called twice is that the command line is
re-inserted in the document (before that we could have created multiple
command lines).
https://github.com/tridactyl/tridactyl/issues/1237 is caused by multiple
command lines being instantiated in the tab. All command lines receive
the "fillcmdline tabopen" message, only one receives the key events
generated by typing stuff in the command line and then they all receive
the "ex.accept_line" message.
There can be two causes ; either Firefox loads multiple Tridactyls
(unlikely) or we load multiple commandlines (more likely). Moving
command line creation out of init() should fix this as the worst that
can happen now when init() is called twice is that the command line is
re-inserted in the document (before that we could have created multiple
command lines).
Before storing bindings in the config, bindings are first converted to
their canonical representation by using toMapstr. The problem is that
toMapstr returns " " instead of "<Space>" when asked to convert a
minimalkey representing a space.
This was a problem while trying to bind/unbind keys that were already
bound in the config (e.g. `unbind --mode=ex <Space>` to disable
inserting completions).
This commit fixes that. It also comes with a config updater in order to
make sure that we do not break `<Space>` bindings for users who might
have created some.
