This just removes the background.ts code that detects whether the user
wants to clobber their csp and adds an error message if the user tries
to `set csp clobber`.
The `csp` setting is marked as deprecated but left untouched in case we
find a way to edit CSP in a way that complies with Mozilla's policies.
The csp-editing code in `requests.ts` is left untouched for the same
reason.
This commit turns hint mode into a real mode. This required several
changes:
- In `src/content/hinting.ts`: create a function named getHintCommands
which returns an object containing functions that can be used as ex
commands.
- In `src/content/hinting.ts`: rewriting the `parser` function to have
it check the `hintmaps` object in the config and trigger these if
they're bound to anything. We can't use a generic parser because
vimperator hints need to catch every single keypress, even the ones
that aren't bound to anything and act on them.
- Creating `src/background/hinting.ts`, which just wraps ex commands
from src/content/hintings.ts in a proxy which will forward calls to the
content script.
We couldn't have just invoked "check for updates" on every single
operation because it would've gone out to the RSS every time. This
refactor permits it to cache a highest known version for a
configurable interval. It should be safe to invoke this new
update-checking logic as frequently as desired.
This has a few moving parts.
First, we need a bit of code for keeping track of what other
extensions are installed and enabled. This isn't completely trivial
because we need to listen for "on {en,dis}abled" and "on
{,un}installed" events. This requires a new permission, `management`,
which is _annoying_, but not having this permission would require
extension detection to be done using kludgy messaging hacks that would
be on the critical path for essentially every navigation operation.
Second, we need to write code to talk to the other addons and ask them
if they're handling things. Thankfully they do provide public APIs and
and we can use their sample code to do exactly what we need to do.
Third, it turns out some important chunks of the firefox webext API
aren't handled by the web-ext-browser ts declaration we're
using. They *are* handled by a PR on @types/firefox-webext-browser,
though, so we can copy and paste that to make TS happy.
Fourth, and finally, we need to add some code to the autocontainer
logic to use the compatibility code. This is pretty easy, but
autocontainer logic starts taking a noticeable amount of time becuase
of all the sequences awaits we're doing, so I also have to tweak
things to do all of the async stuff in parallel.
This commit removes commandline_background.ts. I believe this is useful
because the only thing it did was provide recvExStr, which just
triggered a synthetic "onLine" event the only consumer of which was the
parser. Since we already used controller_background + acceptExCmd in
some places, it made sense to me to directly use controller_background +
acceptExCmd everywhere.
All functions in native_background.ts use browserBg in order to interact
with the native messenger. This means that these functions can also be
used in the content script. This means that there's no point in keeping
these functions in the background/ folder and that there's no point in
having a native_background message type.
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.
Complete a circular buffer so we don't log too much data, config
settings for turning it on and off (default off, becuase performance)
and for changing the size of the buffer, an excmd for dumping the raw
json so you can pore over it, and for when you just want to
sanity-check yourself instead of groveling over your data for six days
with a deep learning toolkit and three hundred CPUs of compute, an
excmd for pretty-printing your stats in a nice histogram.
I didn't think far enough ahead and only implemented the easy way to
instrument a function, which is with a decorator. I'm getting _really_
angry at typescript not being able to handle decorators on free
functions. bah. I'll figure out a good way to wrap free
functions. Maybe just go the stupid route and make you change
`export async function foo(args)` to `export foo = measured(async
function(args) ...`. But that would break excmd parsing, so... :/
I think that I already want to do a refactor to break excmd.ts into a
bunch of one-line wrappers referencing implementations spread
throughout a bunch of libraries. This would go nicely with that.
Other things I did while I was here:
* Fix the ugliness we had with (window as any).tri by monkey-patching
the tri property into the window object in tridactyl.d.ts
This PR implements site-specific settings. It requires multiple changes
and new features.
First, I needed to create a new value in `window.tri` named
`contentLocation`. This contentLocation object is either a Location or
URL object containing the URL of the currently selected tab of the
currently selected window. This is required because config.get() is not
asynchronous and we probably want to keep it that way, thus we can't
message the content script just to get the current url.
Then, we create a new object, URLCONFIGS, in content.ts. It behaves
exactly the same as USERCONFIG, except it has a level of indirection,
matching url patterns to config objects. This requires creating new
seturl, geturl and unseturl functions which behave mostly the same as
set, get and unset.
Last, we create a `seturl` ex command in order to interact with this new
object.
