This means that there's now a canonical script that allows other
distributers to build Browsh. The only caveat being that the web
extension cannot be built (Mozilla only allows one signed `.xpi` per
version), so it is downloaded.
My hunch is that, since the switch to using brow.sh as the default
homepage, the extra page load time has an undesirable effect on
subsequent requests for new tabs. For example, say that a new tab
is requested but the original brow.sh tab hasn't completed, but
it does complete halfway through another tab loading. Might it retake
focus and prevent DOM load events triggering in the user-requested
tab?
So for now, the quickest fix is just to increase the wait time in the
tests. The better fix, if my hunch is right, would be to detect and
wait for the original launch-time tab to finish.
Such a big commit to provide a fix which really only involves a few
lines in the graphics builder. It would seem that the very first time
the BlockCharMono font is rendered it needs a little delay. So there's a
refactor here to use a callback when requesting a screenshot with text.
All the other code in this commit is just the scaffolding to try to fix
this issue. It's all good stuff in itself. Basically stricter code
triggers for the different stages of page load: tab load, DOM ready,
page ready. I actually wonder if the TTY page loads feel snappier now?
closes#46
Only 'next-tab' is currently supported.
You will need to run Browsh with `--debug` then press the key
combination and watch the logs for something like;
`TTY sending: /stdin,{"char":"\u001c","key":28,"mod":2}`
That is the result of having `pressed CTRL+\`. Then add something
like the following to your config file:
```toml
[tty.keys]
next-tab = ["\u001c", "28", "2"]
```
touches #52