tridactyl
tridactyl copied to clipboard
tridactyl
Enable tridactyl to run in chrome
See https://github.com/tridactyl/tridactyl/commit/3ff84e61661b955e478f523437cf73144e8ff1d5 for how to fix the CopyWebpackPlugin errors - when you merged master in, you'll have updated the plugin to a version with a new API.
Lots of Tridactyl seems to work fine on the "options" page. That's really cool!
What you said in the previous issue has worried me a little bit:
I will now try to find all of the places where tridactyl fails in chrome and make issues for them.
I can pretty much guarantee that you won't be able to find all of the places where Tridactyl doesn't work in Chrome - Tridactyl is just too big and has a massive number of configuration options.
Even if you did find everything that worked in Chrome but not Firefox, we'll almost certainly add something in the future that does break Tridactyl in Chrome.
I think it would be more productive to focus on allowing/encouraging Tridactyl developers to access browser. in a way that is safe across the browsers. So, e.g. :tab completions, rather than just not working at all in Chrome because Chrome doesn't have container support, would not show container icons in Chrome.
Web extension API compatibility across browsers is available programmatically here https://github.com/mdn/browser-compat-data/tree/master/webextensions/api - I don't know if we could develop something that used that with TypeScript to warn us when we hadn't dealt with a property that might not exist. I think that's my ideal situation: if I tried to use browser.firefoxOnlyProperty.function, I should get a compiler error unless I used browser.firefoxOnlyProperty?.function and dealt with the possibility that it might be undefined.
I think @saulrh had some ideas about this, so I'm pinging him here :)
I think @saulrh had some ideas about this, so I'm pinging him here :)
Let me go see if I left any notes for myself...
A comprehensive list of known incompatibilities maintained by Mozilla. It's mostly intended for chrome->ff ports, but it should help in both directions. It shouldn't be too hard to audit tridactyl's codebase for the slightly more subtle violations. Certainly won't catch anywhere near anything, but after a while you should start getting a rough idea of what parts are more or less dangerous.
I don't know if we could develop something that used that with TypeScript to warn us when we hadn't dealt with a property that might not exist.
Should be... vaguely possible to write a script that reads that and spits out a .d.ts that overrides the browser declarations with optionals in the right places? You'd lose a lot of the fancy type-checking that you get from web-ext-types, so it'd have to go in some kind of separate linting step or something. Not great.
I'm surprised that web-ext-types doesn't already do the right thing wrt parts of the spec that aren't implemented in some places.
Huh. Actually, looks like someone has already done this! https://github.com/Lusito/webextension-polyfill-ts
How do we want to structure the docs for tridactyl-on-chromium? Do we have them off on a separate page? Do we document inconsistencies inside specific commands?
We should probably think about designing some way to annotate excmds as working/not working on different platforms so we can raise error messages like "This is a known bug" rather than getting issue tracker spam.
I think I'd like one source of documentation for all versions of Tridactyl (partly so Chrome users can see what they're missing). We should probably be able to annotate ex-cmds as missing so that they do not show up in completions.
Ideally whatever we choose will be general enough to make supporting different Firefox versions (e.g. ESR) / Firefox for Android not too much extra work.
I haven't had time to check that the polyfill you linked to does this, saulrh, but https://github.com/Lusito/forget-me-not/blob/develop/src/background/background.ts#L113 is exactly the sort of thing I want to compiler to persuade us to do :) (except with optional chaining as that's much more ergonomic).
Merge branch 'master' into chrome-port
Note for @MatiasStorm unrelated to this PR: I generally recommend trying to rebase branches onto master instead of merging master into them. It's not necessary (or possibly even worth the time) in cases like this, but for higher-complexity projects it makes it a lot easier to follow other recommendations about clarity of history.
As an example of "history clarity recommendations": When I have a feature I'd like to add, the last thing I do before sending off a pull request is go back through my changes and re-group them into a totally new series of commits - sometimes even a series of independent pull requests - based on logical function rather than the coincidence of what order I wrote the changes in. This makes it so that the code can be reviewed, debugged, bisected, and rolled back in the smallest possible units. This is substantially easier to do when I've been rebasing my changes onto master instead of merging master into my branch.
Can this be merged into master or do i need to make more changes?
One minor change - which I'm happy to do as I merge it - is that the yarn.lock file should be committed. That helps to ensure that our builds are reproducible as it is a record of all of the exact versions of dependencies used. I've just noticed that our CI would pass even if the lockfile changed on yarn install - I've fixed that on master now.
The other issue is that I'm slightly uncomfortable with merging this as it stands as the Chrome port doesn't work very well, so no-one will use it (yet). I don't want unused code to stay in Tridactyl for a long time. OTOH, I appreciate that un-merged code gets stale and is annoying to fix tp.
So, I'll merge this if you pinky-promise to tell me if you decide to abandon the Chrome port so that I then know to un-merge it :) . I am bad at noticing these things on my own (see https://github.com/tridactyl/tridactyl/commit/10b00b4f6849d5ef0093ebc63138a367c359f36c which survived unused in Tridactyl for a whole year).
I have added yarn.lock.
I didn't really think about it that way but now that you say it, it might be wiser to wait merging this. At least until #2460 has been resolved.
I'd be willing to switch to Chrome as my daily driver until we have some users migrated, if that helps.
Hey, I just want to know how the progress for the issue is. I really want to use Tridactyl in Chromium-based browsers. Is there a way to do it now? I can see the label as blocked. When shall we expect this? Last activity on this issue (discussion) was on 2020-06-20 as I can see.
I'm curious to know if there is still a path forward to enable Tridactyl to run in Chrome. Thank you!
On Tue, Apr 09, 2024 at 06:52:26AM -0700, Sarath Addanki wrote:
I'm curious to know if there is still a path forward to enable Tridactyl to run in Chrome.
I don't mean to speak for @bovine3dom here, but there are multiple important architectural differences between Firefox and Chrome(ium) extensions. There's certainly a path forward, but (from what I understand) it would require the implementation of new APIs in Chrome(ium) in order to support the extension's use case. Some of these APIs existed, but were nerfed because of the v2 Manifest depreciation.
For more information, issue #1619 might be helpful.
Yeah, pretty much what stupidcomputer said:
- For Manifest V2, we can port to Chromium pretty easily, we just need to play whack-a-mole with the linter, adding guards around Firefox only features such as containers. But Chrome is not accepting new Manifest V2 extensions, so this would not be very useful to people who want a public release.
- For Manifest V3, we would need to do a rewrite of Tridactyl's architecture. In theory we'll have to do that anyway eventually because Firefox wants to move to V3, but I am telling myself that Mozilla will not make the switch for a few years. Google used Manifest V3 as an excuse to tighten restrictions on code that changes at run-time, meaning things like
:jswould probably have to be disabled.