Open Mottie opened 2 years ago
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/)
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.
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.
An update on this: Mozilla is planning general availability of MV3 extensions on Firefox for Android. NOT MV2 extensions.
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.
MV3 still doesn't implement a way to ensure the styles are applied in time to avoid FOUC (flash of unstyled content):
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:
developer mode
switch in chrome://extensions, which is often disabled in managed browsers;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).
@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?
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.
OK, fair enough...
https://developer.chrome.com/blog/mv2-transition/