ferdi
ferdi copied to clipboard
Add support for extensions
This is an updated version of the PR in getferdi/ferdi#822. Due to the many changes in the develop branch and a failed attempt of merging the two again, this updated PR and branch has been created. I am not completely done moving all changes into this branch so there are probably bugs when trying to install/open/use this branch.
Description
This PR adds support for basic chrome extensions to Ferdi. It based on the new Electron Extension API. Using this, Ferdi can support basic extensions that don't require too complex browser APIs. This method will not be able to support all Chrome extensions! Supporting all Chrome extensions would require mocking the complete Chrome Extension API which is not a possibility with a small Team like Ferdi's. We can however expand and mock small parts of the extension API in the future if there are large requests to do so.
Similar to Ferdi recipes, Extensions will be stored in %appdata%/Ferdi/extensions
. The goal is to have an easy-to-use UI, similar to the current recipe UI that allows installing and configuring extensions right from inside Ferdi.
Development and Testing Extension
Based on sentialx's test extension, I've created this basic extension to test and develop the extension feature:
Place the contents of the zip into %appdata%/Ferdi/extensions/extension
, switch into this PR's branch and it should automatically be loaded. In the service develop tools you should now see a basic "Content Script Loaded" and the results of the background script test:
What is done
- [x] Implement basic code to load extensions
- [x] Build a feature controller that handles loading extensions into the webviews and container session (
src/features/extensions/index.js
) - [x] Implement basic settings window for enabling/disabling/configuring extensions
What still has to be done
- [ ] Implement an "extension store" similar to the recipe store already available (see Section below for more information) (I'm currently working on this one)
- [ ] Implement Browser APIs (see more info below). We will also need to find a good way on how to implement/structure these APIs to make them maintainable. The current implementation should only be viewed as a "quick proof-of-concept" and can probably be greatly improved
- [ ] Implement Updates
- [ ] Test, which extensions are compatible
- [ ] Polish UI design and UX
Browser APIs that need to get implemented
- [x] Unrecognized manifest key 'author'. (Not important, doesn't need fixing)
- [ ] Unrecognized manifest key 'browser_action'.
- We will need to somehow implement browser action icons (the ones in the top right of your browser). Let's see if this works 😬
- [ ] Unrecognized manifest key 'commands'.
- This will be something that we implement in the future. Commands are keyboard shortcuts for extensions, so this won't be a priority for the first release
- [x] Unrecognized manifest key 'minimum_chrome_version'. (Not important, doesn't need fixing)
- [x] Unrecognized manifest key 'short_name'. (Not important, doesn't need fixing)
- [ ] Unrecognized manifest key 'storage'.
- I haven't heard of "managed schema" storage for extensions yet, will have to look into that.
- [x] Unrecognized manifest key 'update_url'. (Not important, doesn't need fixing)
- [ ] Permission 'contextMenus' is unknown or URL pattern is malformed.
- We'll have to see if and how we could implement context menu creation for extensions
- [ ] Permission 'privacy' is unknown or URL pattern is malformed.
- Haven't worked with the extension privacy API before so I don't really know what that is about
- [ ] Permission 'tabs' is unknown or URL pattern is malformed.
- Of course tabs is unknown as Electron doesn't have tabs itself. We'll have to see whether we need to implement the whole API or just parts to get the current tab
- [ ] Permission 'webNavigation' is unknown or URL pattern is malformed.
- As far as I can tell, this is the API to actually block requests before they trigger. I had hoped that this API would already be implemented as I don't know if it is possible to intercept requests like that using normal JavaScript
- [ ] Cannot load extension with file or directory name metadata. Filenames starting with "" are reserved for use by the system.
- We might need to delete the "_metadata" folder after installations so this doesn't happen
Please write if you want to take up any of the tasks as we'll need to collaborate in bringing this feature to life 😄. Please also write if you know any other tasks that would need to be done.
The extension store
The extension store is place for us to showcase extensions that are tested to work with Ferdi. I suggest we add a new file like extensions.json
to Ferdi source which contains a list of available extensions.
Those extensions could then be downloaded directly from the Chrome WebStore (see https://stackoverflow.com/a/7185195/10590162), so we don't can be sure that we always download the newest version of an extension.
Motivation and Context
Extension support is a feature requested by many users of Ferdi (#113).
Checklist:
- [x] My pull request is properly named
- [x] The changes respect the code style of the project (
$ npm run lint
) - [x] I tested/previewed my changes locally
It looks like the Electron community has already worked on implementing some of the Chrome Extension API: https://www.npmjs.com/package/electron-chrome-extensions This should simplify extension support for us! Additionally, the now-open-source Station (https://github.com/getstation/desktop-app) already has extension support using that package which should serve as an example implementation for us.
Is this PR going to be dropped? I am looking for extension support in ferdi, is there anyway I can help?
Is this going to be implemented? Also, what happened to the github issues they have disappeared. I was looking for the issue referenced here: #113 but there is no longer an issues tab.
What happened to this PR @vantezzen, please do not tell me you are keeping this feature for an eventual "paid" version?
I came from Rambox to Ferdi, in the hope of finding free support for extensions, because it gives me the possibility to use Grammarly in all apps. Am very disappointed that this feature is not given importance. What a shame!
fullack to @mysticaltech for me, it was also a reason to migrate from rambox to ferdi to use extensions like grammarly.
There must be a way to integrate extensions to the receipts. Like crossloading the .crx into the services electron instance... Any way to do this without necessarily integrating it for everyone?