Added a new script to package the webextension. This will automatically
build and zip the source code and the webextension for upload. It take a
version as an argument and then checks the version in the manifest, and
locally commits a version bump.
Note that getMessage in the badge depends on having a complete set of
translations, unlike the webextension, which will fallback to the
default for a string.
Because the timeout makes the pair inactive, we should check for this
state in onopen before connecting to the client. Updated tests to set
the proxy pair to active before testing onopen. Also removed a
redundant statement.
The former icon used fill="context-fill", which I believe doesn't work
except in Mozilla's own extensions. So I changed that one to
fill="black" and made a new one with fill="white".
https://bugs.torproject.org/31170#comment:8
I chose these icons for the "on" and "off" icons:
toolbar_icon_purple.svg → toolbar-on.svg
toolbar_icon_grey.svg → toolbar-off.svg
I then made toolbar-running.svg by copying toolbar-off.svg and changing
the stroke and fill from #4A4A4F to #40E0D0.
In Firefox, this requires version 67 for support for
prefers-color-scheme media queries.
https://hacks.mozilla.org/2019/05/firefox-67-dark-mode-css-webrender/
To force Firefox into dark mode, set ui.systemUsesDarkTheme=1 (and
optionally browser.in-content.dark-mode=true, to put pages such as
about:addons into dark mode as well) in about:config. You can check if
it's working at https://bugzilla.mozilla.org/, which has its own
dark-mode styling. Note that this kind of dark mode is *independent* of
the "Dark" theme that can be selected in about:addons.
Chrome requires version 76 for prefers-color-scheme. You can force it by
running with the --force-dark-mode command-line option.
This one was missing from the redesigned icons. I made it by making a
copy of status-on.svg and changing the fill from #8000D7 to #40E0D0.
I didn't make a separate dark-mode version of the icon.
This is similar to the deadlock bug in the proxy-go instances. If the
proxy-pair sends an answer to the broker, it previously assumed that the
datachannel would be opened and the pair reused only once the
datachannel closed. However, sometimes the datachannel never opens due
to ICE errors or a misbehaving/buggy client causing the proxy to
infinitely loop and the proxy-pair to remain active.
This commit reuses the pair.running attribute to indicate whether or not
the datachannel has been opened and sets a timeout to close the
proxy-pair if it has not been opened by that time.
