The userScripts API is ready for testing in Canary so I'll start migrating. It should improve/simplify performance for many scripts, but the API has a few nasty limitations such as the lack of tld, regexps in @include, no smart blacklist. It means I'll have to come up with possibly complicated workarounds...

@tophf what's the latest on this? Is V3 workable?

It looks like they have announced June 24 for V2 deprecation https://developer.chrome.com/docs/extensions/develop/migrate/mv2-deprecation-timeline

Nothing's changed, it's just as bad. We'll use the new API eventually though.

I'm also waiting for them to remove the highly problematic requirement to enable developer mode in chrome://extensions page for every user of the extension. As long as it's present I'm reluctant to work on the new API and I'm even prepared to use the ExtensionManifestV2Availability policy locally myself and promote it until Chrome implements a proper solution.

I believe that Manifest v3 is possible. There are userscript managers for Safari that use MV3. I'm certain there will be a sacrifice in the power of userscripts, though.

@tophf MV2 will become disabled in pre-stable versions of Chrome (Dev, Canary, Beta) in June 2024. In Chromium 127 MV2 will be disabled. Current version is 124. 127 will come in 3 September 2024, so there's 4 months left to transition. This thread has a lot of info (which as I just checked, you have contributed to). Additionally Tampermonkey Beta has switched to MV3.

I'm not sure we should update our stable extension because MV3 breaks some things and there's no good substitute yet, we should probably suggest the users to enable the policy to prolong ManifestV2 as shown here for Windows, we should probably describe examples for all platforms somewhere.

As for beta, I don't know. Maybe. I was planning to do it anyway this month.

@tophf Why not have one extension that is MV3 and one that is MV2, like uBlock Origin & uBlock Origin Lite? How much functionality is lost in MV3?

I've listed some issues I remembered in Tampermonkey thread.

@tophf Why not have one extension that is MV3 and one that is MV2, like uBlock Origin & uBlock Origin Lite? How much functionality is lost in MV3?

Based on TM MV3 Beta, even the GM_setValue GM_getValue can be reserved without changes.
It looks like no functionality loss in the current MV3 spec can be achievable, just except the webRequest related issues to be confirmed.

I have seen the frequent updates for VM.
Can you just frozen the current beta version to 2.19.0 and then focus on the MV3 version?

I don't think the minor updates in the current VM 2.18.x is necessary. They are just minor UI issues. It should become a stable version.

The problem with GM_getValue is different and it doesn't affect everyone. There are other problems I've listed.

Excited for this - while MV3 is really annoying in a bunch of ways, Chrome continues to make MV2 harder and harder to use, especially in compliance-heavy environments.

@tophf #1934 (comment)
we should probably suggest the users to enable the policy to prolong ManifestV2 as shown here for Windows

This solution to keep Manifest V2, based on HKEY_LOCAL_MACHINE registry, requires administration rights on Windows. :-/

It might work for the user account if you replace HKEY_LOCAL_MACHINE with HKEY_CURRENT_USER, could you test?

Update: works for me.

https://github.com/BlackGlory/eternity is based on Manifest V3 and is working for me.

Instead of rewriting everything, perhaps we could have Violentmonkey based on it, add support for the GM* API, and port the current user interface?

We don't need to rewrite everything either, it's not the problem.

@tophf Will Violentmonkey still be on MV2 when the end-user transition begins next week? I take it from this thread Violentmonkey will require users to edit the registry (Windows) or install profiles (macOS) for functionality to work once the end-user transition begins.

Chrome will show a button to keep the extension, so depending on how many users do that Chrome developers will decide on the availability of this button.

I still think it would be a good idea to update at least the Beta extension to MV3 or create a new extension (based on Violentmonkey) that is MV3-based. While MV3 removes a lot of the power of MV2-based userscript managers, it greatly improves security and efficiency. If there isn't an ongoing attempt to port it to MV3, I may do it myself in a fork (and eventually push upstream if desired).

MV3 [...] it greatly improves security and efficiency.

It doesn't, those claims are greatly exaggerated to the point of being unsubstantiated propaganda.

• Nothing changes in regards to security for users of extensions that didn't do anything insecure.
• Efficiency is lower for extensions like ours that need to process every navigation because MV3 disallows persistent background scripts, which means it will restart hundreds of times a day wasting resources much more than in MV2. No one in Chrome team has ever measured the impact, they just believe in an idealistic notion.
• MV3 userScripts API doesn't support regular expressions, so extensions have to run all such scripts in all tabs and frames, and perform the check there, which means that every regular expression will be recompiled again and again without caching, thousands of times each day. The scripts may be very big, so megabytes of code will waste the CPU time and battery without being actually used.
• MV3 userScripts API doesn't support smart blacklists offered by Violentmonkey, see the previous consideration minus the regular expression compilation.
• MV3 userScripts API doesn't support setting GM_setValue separately, so we have to re-register the entire script and embed its storage data alongside the code, because GM_setValue/GM_getValue are synchronous and the data must be present at the moment the script runs. Re-registering is a complex operation inside the browser, so if we do it every time the script changes a value via these GM functions, the overhead will be staggering. We could throttle these updates, but only by a few milliseconds, otherwise when the script reloads the tab the old incorrect data will be loaded.
• If we don't use the very limited MV3 userScripts API, we can't ensure the scripts will run at document_start:
  • "synchronous page mode" option won't be available as MV3 removes webRequestBlocking
  • the background script will need 50ms - 500ms to start and load the scripts every time navigation occurs after a pause of 30 seconds, which may easily happen hundreds of times a day.

I think we will make an MV3 version anyway because userScripts API offers some good features like world isolation and true document-start.

While MV3 removes a lot of the power of MV2-based userscript managers,

This might not be true because the author of Tampermonkey has investigated how to use the new APIs to do the same as MV2. Only GM.webRequest is lost.

The TM MV3 beta is already released and you can find the crx download link in TM github repo issue.

Tampermonkey MV3 version has all the problems I've listed. But indeed, the power is practically the same, so @cyfung1031 is correct.