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

Switch to manifest v3 #1430

Open
Mottie opened this issue May 30, 2022 · 9 comments
Open

Switch to manifest v3 #1430

Mottie opened this issue May 30, 2022 · 9 comments

Comments

@Mottie
Copy link
Member

Mottie commented May 30, 2022

https://developer.chrome.com/blog/mv2-transition/

January 2023: The Chrome browser will no longer run Manifest V2 extensions. Developers may no longer push updates to existing Manifest V2 extensions.

@Freeplayg
Copy link

Freeplayg commented Jun 2, 2022

Firefox doesn't yet support v3, although I think they are planning on adding it soon. So I would wait

we expect to launch MV3 support for all users by the end of 2022
(https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-firefox-recap-next-steps/)

@tophf
Copy link
Member

tophf commented Jun 3, 2022

Chrome doesn't support all the things we need too, like passing a config to content scripts synchronously or creating nested workers in the background context. These things may appear only next year, but we'll have to start the migration sooner because it takes time. We'll keep the MV3 version separate somehow, so that the ongoing work doesn't break the main extension in older browsers.

@narcolepticinsomniac
Copy link
Member

Makes you wonder if they're kickin' the can because there's already been a more significant, preemptive backlash than they originally predicted. The memes about Google killing adblockers, and how everyone should switch to Firefox, have certainly been making the rounds in recent weeks.

I'm sure it's all a numbers game to Google. How much of their market share monopoly are they willing to sacrifice for increased ad revenue? No doubt they have projections which legitimize the shady moves they've been planning for years now, but obviously something's changed. Predictions are all well and good 'till the pitchforks come out.

@Poopooracoocoo
Copy link

An update on this: Mozilla is planning general availability of MV3 extensions on Firefox for Android. NOT MV2 extensions.

@ZatsuneNoMokou
Copy link

https://developer.chrome.com/blog/resuming-the-transition-to-mv3?hl=en

We will begin disabling Manifest V2 extensions in pre-stable versions of Chrome (Dev, Canary, and Beta) as early as June 2024, in Chrome 127 and later.

@tophf tophf pinned this issue May 25, 2024
@tophf
Copy link
Member

tophf commented May 25, 2024

MV3 still doesn't implement a way to ensure the styles are applied in time to avoid FOUC (flash of unstyled content):

  • background script cannot be persistent and if you pause browsing for 30 seconds it'll terminate, then you open another page and the background script starts again (50-100ms), reads all styles to find the matching ones (20-200ms depending on the amount of styles), which almost always guarantees a FOUC on a fast site that open in less than 50ms (simple pages, sites with service workers, going back/forward when not in bfcache);
  • prolonging the lifetime of the background script artificially is forbidden by the web store policy;
  • the instant inject mode doesn't work with declarativeNetRequest because it can't use dynamically-calculated values on a response for a request that was already sent before we can add a dynamic rule.

The only way to avoid FOUC is to use the userScripts permission, but it's also problematic:

  • it's reserved for extensions that allow running external JS code, so the web store is likely to reject our CSS extension due to their single-purpose policy;
  • such ability is perceived as dangerous by many people, so even though we can guarantee no external code will be executed, it may still make people cautious;
  • it requires enabling developer mode switch in chrome://extensions, which is often disabled in managed browsers;
  • it doesn't support regexp matching, which is used in many popular styles, so we'll have to inject all these possibly huge styles into all pages/frames in inactive state and check each regexp against the current URL i.e. instead of super fast check using pre-compiled regexps in our ManifestV2 extension, the browser will recompile all these regexps in each time tab/frame. Just one GitHub Dark is 800kB with ~10 regexps in one style. Checking several such styles on every page would cause a noticeable delay.

In other words ManifestV3 is inherently inferior for userstyles as observed with the original Stylish extension if you open a page, read it for more than 30 seconds, open another page on a fast site. It seems unreasonable to break Stylus as well, so I think we should just keep using ManifestV2 until a native API is implemented.

ManifestV2 can be enabled for a year via policies or registry (if you're not an administrator, replace HKEY_LOCAL_MACHINE with HKEY_CURRENT_USER).

@jacekkopecky
Copy link

@tophf I don't know the complexities here, but if I understand instant-inject correctly, it could enable a workaround I could live with as a user - instant-inject a style that hides everything while the background script is starting and finding the right styles to apply.

Your calculations make it sound like very fast sites would have up to 300ms delay in showing up. I could live with that.

What do you think?

@tophf
Copy link
Member

tophf commented Jun 14, 2024

That's completely unusable i.e. I don't see the point of maintaining Stylus if that's how it has to work. Also, many sites open within 100ms, especially those that have a service worker installed e.g. telegram may start opening (onCommitted) in 30ms since the earliest moment the URL becomes known (onBeforeRequest).

It'd be especially bad when navigating the same site with a style that applies differently depending on the page URL because pages could be loaded very fast and they look similar, so hiding the old contents would be very disruptive and ugly.

I guess I'll try userScripts permission, which is the only reliable solution in ManifestV3, but a) its implementation in Chrome is irrationally dependent on the devmode switch and b) it may be disallowed in the web store since our extension's purpose is not userscripts, c) it's wasteful in regards to the regexp as I explained in my previous comment.

@jacekkopecky
Copy link

OK, fair enough...

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

7 participants