Firstly, this improves performance on a larger pages. But it also
prevents browser crashes a very large pages by setting a limit to how
much work is done per frame.
Also includes:
* Thread safe cell map for simultaneously reading and writing to the
buffered frame of TTY cells.
* Improved webext tests so that they programmaticlly build DOM rects
based off simple text strings.
* CLI is now prepared for supporting multiple tabs.
* Refactored global vars into relevant files
* Now using real types in JSON sent to CLI
* Still doesn't fix integration tests
This offloads significant CPU load from the browser. However it's become
clear that the previous feature of parsing the entire DOM needs to have
an upper limit imposed. For instance large Wikipedia pages still cause
problematic CPU load.
This commit does not fix the broken UI so integration tests fail.
Instead of mirroring the browser's viewport, as if we had a camera over
the browser, the entire DOM is now sent in the frame. This means that
the CLI itself can scroll without having to wait for updates from the
webextension screenshotter.
The biggest refactor is separating out the DocumentBuilder from the DOM
Manager.
I also made consistent use of the mixin pattern I'd only half
implemented.
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.
This was primarily to get native diff'ed frame rendering.
Termbox-go doesn't support true colours, thus the switch to Tcell, but
as it turns out Tcell claims to have wider platform support, so it looks
like an especially good change.
So now the CLI will only try to update the terminal screen when cells
actually change. This has some significant performant gains, especially
when using Browsh over SSH.
Also note that this required a complete change of the frame data
structure sent over the websocket. Previously it was a little
structured, but now it is just a plain 1 dimensional array of pure
strings, even the RGB components are sent as integers in strings. If I
can find a way to unmarshal mixed arrays in Golang then it'll be worth
sending a mixed JSON array to save some compute overhead.
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.
