Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[Bugs/Features] Firefox/Firefox Forks #169

Open
OdinVex opened this issue Mar 3, 2023 · 2 comments
Open

[Bugs/Features] Firefox/Firefox Forks #169

OdinVex opened this issue Mar 3, 2023 · 2 comments

Comments

@OdinVex
Copy link

OdinVex commented Mar 3, 2023

Firefox forks such as the ever-popular LibreWolf aren't currently supported by Yin-Yang.

Several fixes need to be introduced to more easily support any/all:

  • Update the Yin-Yang “Firefox” extension to report the customized browser name in the browser.runtime.sendNativeMessage call. Instead of sending “firefox”, send the browser name and vendor for best results. This allows the extension to work on any version or fork of Firefox (provided they have their copy of the native-messaging json in the proper location). I would attempt to turn communication.py into something universal.

  • Patch communication.py by simply reducing the messaging around the “Firefox” assumption: _send_message(_encode_message(send_config(message_received))) resolves this easily and lends itself to universal use.

  • For LibreWolf, the appropriate directory is ~/.librewolf/.

  • Firefox/LibreWolf are not communicated to from Yin-Yang when Yin-Yang is started or 'Apply' is pressed. Yin-Yang should 'communicate (send_theme)' on startup and on configuration change. Perhaps swapping over to port-based native-messaging might be a good alternative...or periodic polling by the extension as a last resort. Restarting software everytime is the only alternative.

@l0drex
Copy link
Collaborator

l0drex commented Mar 7, 2023

We would have to create new plugins that subclass the Firefox plugin. Otherwise, they would use the same configuration if both are installed (although I'm not sure if that would be a problem).

If sharing configs between them is ok, it should be enough to include the profile directories in firefox.py.

@OdinVex
Copy link
Author

OdinVex commented Mar 8, 2023

We would have to create new plugins that subclass the Firefox plugin. Otherwise, they would use the same configuration if both are installed (although I'm not sure if that would be a problem).

No, you only need to update one line of code in your Firefox extension to not report 'firefox', but rather the vendor. I made all the changes for everything I mentioned in this Issue, but I trashed the project once I found Firefox's built-in System theming which is automatic.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants