"If all you have is a 3kbps connection tethered" --> "If you only have a 3kbps internet connection"
"But traditional text-based browsers..." --> "However, traditional text-based browsers"
"lack JS support and all other modern HTML5 goodness." --> "lack JS and all other modern HTML5 support."
"few more hours life" --> "few more hours of life"
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
Includes change of CLI args, many of been moved to the config file and
those that remain begin with `--` not `-` and may be worded differently.
Touches #37
This was caused by misunderstanding of the finer details of strings,
runes and slices. I just changed the input_box struct to use runes and
then followed the trail of type errors until input_boxes only ever used
strings to send their text outside themselves.
Closes#93
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 .
Changed "Why?" to "Why use Browsh?"
Removed avoidable phrases such as "that" and "and uses that"
Divided a run-on sentence by using a period
Switched "Firefox =>57" to "Firefox 57 (or higher)
Shortened the documentation sentence and link
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 is the wrong way round, it should default to binary as that's what
most of the OS's are and just set the zip override for `darwin`.
Watch this issue for updates:
https://github.com/goreleaser/goreleaser/issues/720
Possibly helps everyone in #63, #73 and #94
Whether it solves the issue or not, this definitely fixes a bug.
`CurrentTab` doesn't refer to anything until the first frame is received
from the webextension, yet tthe `handleMouseEvent` function can be
triggered long before that.