The problem with the current :viewsource is that it loads a page in
which Tridactyl is not loaded. This commit fixes this by enabling a new
setting, "viewsource" which can be set to either "default" or
"tridactyl". If "tridactyl" is selected, then :viewsource will load the
source code of the HTML page in the current page instead of redirecting
the user to the view-source:// version of the page.
This function accepts a callback as argument that will be called once
the commandline has been removed from the page. After the callback has
been executed, the commandline is re-inserted in the page.
Changes summarised in doc/changelog.md. Additionally, change version
excmd to stop copying to clipboard as it was causing the command line to
be hidden, and add version number to the new tab page.
Turns out writing to browser.storage is expensive because state.ts and
config.ts both listen for it in every tab. I'd vaguely assumed that
Firefox would run other tabs as low priority tasks and that this would
not be an issue, but it doesn't.
I also wrote the code in a rush, and while I mused that this potential
risk exists I didn't document it or explore it.
Retrospective: Content switches are expensive - think before you do
anything that may wake many processes and don't make wild assumptions
about how Firefox handles multiprocessing.
This reverts commit 092e501db4.
This was causing a bug identified by @glacambre and @Lexi where
sometimes the html function isn't defined when returning to a page with
history back.
Personally, I think it's probably webpack or Firefox's fault: content.ts
clearly imports html-tagged-template as it's first action.
If it's not their fault then it's html-tagged-template's fault: it must
be refusing to set window.html.
This commit makes Tridactyl aware of elements made interactive through
JavaScript and lets Tridactyl put hints on them.
Something possibly dangerous is done here: exporting a function to the
page's context. While it is believed that the current implementation is
secure and that pages can't discover whether the function has been
exported or not, this might change due to new standards being adopted by
firefox. One of these standards is the Custom Elements api:
https://developer.mozilla.org/en-US/docs/Web/Web_Components/Custom_Elements
It will be necessary to check how Tridactyl behaves once this API has
landed. The status of this API seems to be tracked here:
https://bugzilla.mozilla.org/show_bug.cgi?id=1406825