This is used on the Browsh as a Service platform for anonymous logins,
it does not get used by default unless explicitly called. It is an
external third-party binary and not at all integrated with the browsh
binary itself.
The situation is that browsh logs to a file *inside docker* so for now
the easier way to get at those logs is to include this tool inside the
docker container as well. I'm sure there are ways to completely separate
the concerns here and I hope to do that soon once I settle on the final
infrastructure for BaaS.
This gets around a few problems caused by the fact that Firefox's first
ever run on a new profile is quiet different from a normal startup. Note
that this only effects Browsh in Docker.
In the endless struggle to squash a Travis-specific bug, we now have
screenshots. Currently the screenshots are of the custom block font
state, so you can't read the text. But I'm planning on changing the
default state of the page to use a normal font - such that the
frame builder needs to toggle the block font on to build a frame. This
will make it more likely that screenshots will contain actual text.
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.
After weighing up the options it seems that Golang's termbox-go TTY
library has better support for terminals, and it's cross-platform out of
the box. So this commit is the first working version where the
interfacer launches a websocket server, makes a connection to the
webextension and listens to STDIN from the CLI, sending all input to the
webextenstion.
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.
This proves that frames can be generated on Firefox using the canvas and
a Tree Walker to examine text nodes. Already with little optimisation
frames don't ever take longer than 200ms to render.
Chrome has a MediaStream of the viewport, hopefully that will prove
performant as well.
This doesn't have functioning text colour detection or text occlusion
support. But early research suggests this will possible by comparing 2
screenshots: one with and the other without rendered text.
It was only needed by a UTF8 conversion call in hiptext. Thanks to
another hack where I patch hiptext to just use the actual
Upper Half block character pasted into the file, then glibc
support isn't needed.
Provides almost double the resolution by using the unicode upper
block character, "▀", and setting its colour as with the fg colour
and the missing space below it with the bg colour. Clever stuff.
