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.
Google maps doesn't use a [type=text], or any kind of type attribute for
its search box. Plus it also has a [aria-hidden=true] input box that
Browsh was detecting and covering the actual active search box.
Stackoverflow surfaced a few bugs;
1. For some unknown reason it measures the em value of a single
character as having something like 10,000 pixels width. So for now I'm
just hardcoding the standard measurement of 9x15 for unreasonably large
widths.
2. Its cookie banner used `position: fixed !important`, so needed to
update the sticky fix code in case other sites do the same.
3. The cookie banner with the aplied sticky fix meant that the div just
sat staticlly in the middle of the DOM obscuring other text. So I
started a list of site-specific CSS specifics.
During the text builder process its possible that a character tries to
fit onto a TTY cell that already has a character. There are multiple
reasons for this, the main one being hidden text. This commit changes
the method for deciding the priority of character to using the
`elementFromPoint(x, y)` method.
This commit also includes a fix to re-parse all text when there's a
mousedown event.
Sticky elements are, for example, those headers that follow you
down the page as you scroll. They are annoying even in desktop
browsers, however because of the lower frame rate of Browsh, sticky
elements stutter down the page, so it's even more annoying. Not to
mention the screen real estate that sticky elements take up, which
is even more noticeable on a small TTY screen like Browsh's.
There was a long standing problem where random gaps would appear
between lines. The fix was to change a magic number that adds an extra
few pixels to the reported height of the 'em' character dimensions.
Unfortunately I don't know what this magic number actually does. It
might represent the distance between lines?
I think with the recent change to the method of hiding text by using a
dedicated blank font, the initial page load and parsing (upon which the
HTTP Service very much depends), browser window resizes were causing a
delay in the time taken for text to be properly parsed, resulting in
mostly empty raw text pages.
The fix was to ensure that the BlankMono.ttf font was loaded with the
initial page load, by using the webextensions injected style.css file.
That's that frames 6 times as big as the TTY are passed at once. This
lessens the likelihood of catching a glimpse of unparsed webpage as
you're scrolling down quickly.
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 is so you can immediately clear the URL bar upon toggling. Which
saves you holding down the backspace key if you want to ente a new URL.
Only for input boxes. And SHIFT-ARROW isn't implemented.
No doubt a lot of this code is reinventing the wheel, after all this is
basically now a simple text editor. I'm sure there'll be a few bugs to
iron out.
Using the `-http-server` argument will now start Browsh in HTTP Server
mode. It will accept request like this:
`curl brow.sh/http://news.ycombinator.com`
This will return a plain text version of the Hacker News front page,
with a width of 100 characters, with each line separated by a line
break.
Also:
* Use webextension to navigate URLs instead of the DOM. This means
that crashed pages can still be navigated away from.
* An attempt to implement mouse dragndrop, but it doesn't work :(
Unit tests needed tab objects to be created.
Integration tests needed more max time for start up and to make sure
that the final tab doesn't get closed.
Adding, cycling, deleting. The width of the tab handle is currently
fixed to 20. And if there are more tabs than can fit in the tab bar then
the extra ones just dissapear off to the right, but they can still be
cycled to with CTRL-Tab.
The marks the end of feature development in preperation for a version
1 release.
Input boxes are currently only one line and to not properly wrap. So
textareas are also one line. TBC...
Also includes:
* First implementation of the DOM MutationObserver. This needs to have
an eye kept on it in case some websites trigger too mutatation
events. For now it doesn't seem too bad. Although strangely it seems
to stop on Youtube after about 15 seconds.
Text in the real browser only needs to be displayed when parsing with
the Text Builder in order to get the text's colour and z-index. Text
parsing should be done in frequently as it likely doesn't change often.
However graphics building of the current viewport is set to
automatically parse ever 250ms and it doesn't need to know anything
about text. So there's no point defaulting to having text on and hiding
it for every graphics frame.
This tweak has improved the perforance of the graphics parsing for small
frames (the same size as the viewport) from around 100ms to around 4ms!
There are still some curious and inexplicable CPU spikes when
scrolling... TBC
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.
Thomas Buckley-Houston