Introduces a new option to disable the pixel comparison text visibility
detecting code. There are some situations in which it helps and some in
which it hinders. So for now it is disable by default and can be
enabled through the config file or my pressing F6 in the TTY client.
Also includes a couple of fixes to the HTTP server's text rendering.
This has been a long time coming, but it's still not perfect. Basically
I'm trying to reset the entire environment as much as possible so that
each spec runs in a clean room. Mostly in this commit Firefox is being
killed and restarted for every spec, which has made a lot of
improvements.
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
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
There was a bug where raw text pages would unusually truncated. It
seemed to coincide with the char dimensions being incorrectly
calculated. My only guess was that it was because of race condition on
lightweigh sites that didn't load Browsh's webextension code in time.
So for now it just seems better to hard code the char dimensions, which
should at least be more reliable than the bugs of dynamically
calculating them .
I know this adds another 200ms to page load times, but it prevents pages
with a lot of text not rendering their text. Obviously better to just
fix the original bug.
This came about from using Slack's web client.
Adding the input boxes padding to the DOM box coords makes the TTY
cursor more closely reflect the actual input box. Also using keyup/down
seems more universally applicable than merely kepress
Without getting into the whole CSS transitions problem, this is a quick
solution to ensuring that text both loads as quickly as possible and
also loads aftera delay fo 500ms when hopefully all page load
transitions have completed.
Touches #39
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
Not really sure why but `new MouseEvent` was always sending the coords
to the same place within an element, not matter where you clicked. Now
using initMouseEvent(), the click actually goes to the place on the
viewport where you clicked.