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
It appears that Firefox doesn't always log its Marionette startup, so
instead this commit catches the network error when Marionette is yet to
start and just retries until Marionette is ready.
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 the tab's ID to decide if it was the root tab
(that if deleted would close the browser). However our ol' "friend" the
Firefox Privacy tab can sometimes take the TAB ID=1 hotspot, so now we
just have to call out to the browser to ask it how many tabs are
currently loaded, this is more reliable.
This fixes a bug where pressing return after entering a new URL would
forward the ENTER key to the DOM and sometimes trigger the focussed
result in a Google search.
Suddenly found out about webextensions `webRequests` API, where you can
intercept all HTTP requests. Previously you only got status updates when
the current page fired a `window.onunload` event, which is often a long
time after the initial request to new URL is made.
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.
