This means you can now load the raw text in a browser and the resulting
page will have basic blue links that can be clicked on that will in turn
be loaded by the HTTP service.
A significant feature, so worthy of a minor version bump to;
v1.1.0
Firstly Firefox 60 now throws an error if its run as root inside a
user's home path. Which is great because that revelead my naivety about
using `RUN su user` in the Dockerfile. So now Firefox is running as a
non-root user inside Docker which is what was always best.
Also it turns out that the crude 3 second wait at startup hoping that
Firefox's Marionette had started listening, wasn't good enough. So now
we're actually listening for a log message to know when it's started
now.
Finally make all startup methods use a the post-webext connection state
to send the startup URL to the browser, the other methods just seemed to
flakey.
Includes version bump to 1.0.9
Adjust path in .goreleaser.yml
Boot Firefox before any tests to get any 'first launch' behaviour out of
the way.
Remove pacman build as we're using nfpm instead of fpm now.
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.
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.
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.
