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.
There's a bit of refactoring in order for the webextension to deal with
the new order of initialisation now that config is sent by the Golang
client.
Closes#83
Previously we were using CSS to make the text's colour transparent.
However that proved to cause a lot of problems with pre-existing
transition animations in the host webpage. There didn't seem to be
anyway to disable the transition time for text transitioning to
transparent, without also disabling all transitions.
Also added censorship to password input boxes.
After moving to Tcell and implementing its screen diff updates, we can
no longer watch STDOUT to get frames during integration tests. Instead
we need to use Tcell's SimulationScreen and which has a GetContents()
method. This is actually also a much more robust way of being able to
see what Browsh actually outputs during testing.
Also removes the Mozilla Cliqz disclaimer tab on first startup.
Interestingly it has a carriage return in its HTML page title, which is
of course zero-width. But also the fact that this tab can sometimes load
before the requested tab at startup is a showstopper for automated
tests.
This means that Browsh can now be entirely run just by running the CLI
binary. The client launches Firefox as a subprocess, then connects to it
via the Marionette protocol, installs the webextension and finally
triggers a new tab with, currently, the Google homepage in it.
I was trying to set this up for automated testing as well by installing
the built webextension as a temporary addon, because otherwise you need
to sign the extension everytime with a unique semantic version. However
for some reason I can't quite recreate the environment that MDN's
`web-ext` creates. The extension installs fine but fails to load the
`content.js` script, I can't find a backtrace or any other details about
the failure. So for now, we're just going to have to use `web-ext` as
seperate process and have the client connect to that. Which is what one
should do during development anyway, so it's not a huge loss.
Using JS's `getComputedStyle()` for every character is too CPU
intensive, so instead I'm experimenting with using a custom font
to take the canvas snapshot. The font is made up of only the unicode
block character, which basically fills the entire space given to a
monospace glyph. This also means that we can fairly reliably work out
the visibility (whether it's obscured or hidden with CSS) of text.