Standards are for nerds and the BBC isn't for nerds, that's why they use
regular anchors instead of alternate links in order to point to rss
documents on the following page:
https://www.bbc.com/news/10628494
This commit makes sure these links are also picked up by rssexec.
The getrss command lives in the background for easy communication with
the native messenger and uses a helper, getRssLinks, that lives in the
content script.
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).
