6 Commity (79bd148a60edda31ecfec527976017c4218647bf)

Autor	SHA1	Wiadomość	Data
Thomas Buckley-Houston	c13e8d26f6	Use absolute path to webextension.go asset ... Bump to version 1.0.8	2018-06-11 16:28:00 +08:00
Thomas Buckley-Houston	1acb178fa7	Lots of new integration tests	2018-04-07 11:35:17 +08:00
Thomas Buckley-Houston	74538fed0e	Fix for zero-width chars in page titles ... Also removes the Mozilla Cliqz disclaimer tab on first startup. Interestingly it has a carriage return in its HTML page title, which is of course zero-width. But also the fact that this tab can sometimes load before the requested tab at startup is a showstopper for automated tests.	2018-01-31 15:40:43 +08:00
Thomas Buckley-Houston	9a82182a9a	Don't use `--new-instance`, `-P` when launching FF	2018-01-24 10:59:57 +08:00
Thomas Buckley-Houston	318f5c3c34	First draft of integration tests	2018-01-23 20:04:23 +08:00
Thomas Buckley-Houston	b387f66c69	Launch and install webextension from client ... 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.	2018-01-21 11:56:05 +08:00