This commit removes an if statement that is always true and a caching
optimization that can go wrong.
The caching optimization is the `if (!this.fuse)` statement. This
optimization can be buggy because it relies on this.options not
changing between two calls to scoredOptions but as far as I can tell,
this.options always changes between two scoredOptions calls.
If this.options changes, the array indexes used in searchThis do not
point to the right elements anymore and everything can break
(completions that should be matched disappear, completions with a lower
score get higher priority etc).
As far as I can tell, removing this optimization does not make
completions slower, but I couldn't test this with a large history.
The previous code called realFocus unconditionally. This fixed
https://github.com/cmcaine/tridactyl/issues/768 but broke
allowautofocus.
The new code makes sure to check the user's allowautofocus setting
before calling realFocus. I am not sure why it fixes#768 but I believe
it might be because bandcamp relies on synchronicity and that the
previous code used await.
The problem was caused by elements having their scroll-behavior set to
"smooth". This meant that offsetTop was updated with a delay. The delay
made Tridactyl that the element couldn't be scrolled at all and thus
scrolling failed.
This commit has the nice side-effect of disabling smooth scrolling ig
"smoothscroll" isn't set to "true" in the config.
This fixes https://github.com/cmcaine/tridactyl/issues/762.
In firefox 61 there has been a medium change to how the status panel
(that shows the link the user hovers over) is created. Compare firefox
changeset 18bbbdc02213:
https://hg.mozilla.org/releases/mozilla-release/rev/18bbbdc02213
In particular there is no more statuspanel tag. Instead there is an hbox
with id="statuspanel".
This fixes https://github.com/cmcaine/tridactyl/issues/724.
What happened was that sanitise was executed,
browser.storage.{local,sync}.clear() was called, the rest of the
settings were modified and only after this was the onChange event
listener in config.ts called, which then cleared the config.
Awaiting the result of .clear() makes sure that the onChange event
listener is triggered before executing any other command that might
make modifications to the browser storage. This can (and has) been
verified by surrounding the .clear() calls with console.logs and adding
a console.log to the onChange event listener.
When a promise throws an error in l(), the error is automatically logged
in the console. This is a problem because it happens even when the error
is catched by the code that called l(), which might not want to log
errors at all.
l() was necessary when errors thrown in promises didn't reach the
toplevel. Now that they do, it is safe to remove l().
This will enable better error handling.
