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
This is caused (at least in this instance) by sites setting a CSS
min-height rule for `iframe` elements, which is then applied to the
Tridactyl iframe too.
Fix this by adding `min-height: 0` to the CSS for `#cmdline_iframe`.
Because this is an ID, it will always have higher specificity than any
CSS the site sets (unless we collide the ID, maybe), so it doesn't need
important.
Also add `max-height: none` in case anyone tries to cramp our iframe
style.
Perhaps there will be more styles that can mess up the iframe styling
but this seems to fix all the sites reported in #289 and #282. Using
cleanslate might help if it turns out there are very many more ways for
the outer site to ruin our day, but since it's only the iframe that the
site CSS can touch (inner HTML is safe), maybe this will be enough and
save a lot of !important'ing.
