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

Firefox support #21

Open
meain opened this issue Jan 23, 2022 · 16 comments
Open

Firefox support #21

meain opened this issue Jan 23, 2022 · 16 comments

Comments

@meain
Copy link

meain commented Jan 23, 2022

I was wondering what would the effort be to make this available in Firefox. Firefox currently does not support v3 manifest and I believe you are using a few v3 specific keys in the manifest. I am planning to put some time into getting this to work, but just wanted to check if you had done any research in this direction or if there was some specific reason why you went with v3 instead of v2.

@DanilaFe
Copy link
Owner

Hi! First of all, thanks for checking out Matrix Highlight, and for opening this issue. I haven't done too much research into Firefox at this time, but it is my primary browser too, and several people have already voiced a desire for running MHL on Firefox. Here are my thoughts on the feature summary, though:

  1. Background pages VS background services seems like the biggest change. However, I believe that services are actually more restrictive than background pages, so aside from some code changes, it's possible that things will work out of the box.
  2. MHL doesn't do network request modification.
  3. MHL works with manifest V3, which means it loads no external scripts already. Thus, it should still work on on V2.
  4. I use Chrome's promise-based APIs when possible. Firefox claims that it has this in the browser* namespace. Perhaps it won't be too bad to make everything play nicely, but I can imagine there will be some problems here.

It feels to me like the majority of work would be to cleanly make the two versions of the extension coexist in the same code base. In general, I don't know the state of the art of cross-browser development.

I went with Manifest V3 because Chrome is by far the most used browser, and manifest V3 is the "standard" way of making Chrome extensions at this moment.

@DanilaFe
Copy link
Owner

I'm going to give it a quick shot now, and see how far I can get.

@DanilaFe
Copy link
Owner

2022-01-22-220525_3073x2057_scrot
Looks like it's not too terrible :)

@meain
Copy link
Author

meain commented Jan 23, 2022

Damn, that was quick. Looking forward to using it on Firefox :)

@DanilaFe
Copy link
Owner

Me too! I'm keeping this open until I get it working on both at the same time cleanly.

@Stvad
Copy link
Contributor

Stvad commented Dec 29, 2022

Hey there @DanilaFe I was wondering what is the status of the work/if you have your FF branch published somewhere? :)


UPD: oh somehow missed you're the author of the repo 😅. Found the branch!

@Stvad
Copy link
Contributor

Stvad commented Dec 29, 2022

Also, the v3 is now enforced in Chrome =\ (if you want to publish the extension to the store, at least)

@Stvad
Copy link
Contributor

Stvad commented Dec 29, 2022

As far as I can tell the current master in fact supports Firefox!

@DanilaFe
Copy link
Owner

DanilaFe commented Jan 1, 2023

Yes, master should support firefox, but V2 is no longer working in Chrome... As far as I can tell, neither V2 nor V3 works in both browsers. How frustrating!

@Stvad
Copy link
Contributor

Stvad commented Jan 1, 2023

Yeah, it is quite frustrating. v2 still works in Chrome, you just can't publish it to the store =\

I here describe an approach of dealing with it for Parcel bundler: fregante/browser-extension-template#78

@DanilaFe
Copy link
Owner

DanilaFe commented Apr 21, 2023

I've updated both to use manifest v3. The problem is that currently, Firefox especially loves tearing down background pages when they're "inactive" (even if they are active, it just immediately recreates them). This means that at present, the Matrix JS client is re-initialized every 30 seconds or so. If your account has slow syncs (i.e. if you're in a lot of large rooms), well, that will cause some trouble...

The proper solution is to persist the client data somewhere, so that the teardowns aren't as expensive. Even so, it's a huge pain that there's no way to keep a matrix client alive.

@ptman
Copy link

ptman commented Apr 21, 2023

Sliding sync should be much faster. But I doubt any guarantees can be given as to how fast it should perform

@Stvad
Copy link
Contributor

Stvad commented Apr 21, 2023

There is an option to run it in the content script. If you put it in the iframe it'll also run on a separate thread/process making sure it won't block rendering. I use such a simulated background page in https://github.com/transclude-me/extension/blob/main/source/content/background-simulation/utils.ts

@DanilaFe
Copy link
Owner

DanilaFe commented Apr 21, 2023

Thank you for the suggestion, @Stvad!

I was under the impression that content scripts can't do network requests, but maybe the iframe will help with that. Another problem is that I'd rather not create 30 matrix clients if a person has 30 tabs they're annotating. Also, unless each tab has its own "device" / login, there will certainly be race conditions when it comes to receiving syncs and generating transaction IDs for outgoing events.

@DanilaFe
Copy link
Owner

Sliding sync should be much faster. But I doubt any guarantees can be given as to how fast it should perform

I've been a bit out of the matrix ecosystem lately. Is sliding sync available to all, especially via the JS sdk? If so, combined with storing sync results and some other work, that might be the way to go (but older homeservers won't support it, right?)

@Stvad
Copy link
Contributor

Stvad commented Apr 21, 2023

Content scripts def can send network requests, but servers may reject them, depending on the CORS configuration. That's not an issue in case of Matrix servers

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

4 participants