The ongoing saga of Manifest V3 and browser choice.

Ah, the ongoing saga that is Manifest V3 with the current schedule (link) continues as Google insists on pushing forward with it’s schedule:

Even in the light of the growing list of issues that need resolving (link) not to mention unhappy developers who are trying to keep their new projects moving forward while they liaison with Google to get problems sorted (link) it is doubtful they’re going to get MV3 to a position (before the 17 January 2022 cut off where they stop accepting new MV2 extensions) where developers of new extension(s) will find that the framework is suitable. Sure, if you look at the timetable as an existing developer then you’ve got year up your sleeve when you keep updating your applications as you wait for issues relating to MV3 are corrected but that leaves new developers stuck having to deal with MV3 and trying to hurry along Google to get problems blocking ones extension from operating properly.

Below is a video that goes into detail why they’ve made the changes they have:

The issues that were raised the video, I would hazard to guess, are issues that most extension developers would agree are issues that need addressing but the problem is that, like Apple, there was no consultation with the extension developers who maintain the ecosystem. It is a situation of a software company developing something without first asking whether it is suitable for the primary customer who will be using it – in this case the lack of consultation has resulted in parts of Manifest V3 that are not fit for purpose.

With that being said, I wouldn’t be surprised that we’re going to see Manifest V3 serving as the basis of the future work being put out by the ‘WebExtensions Community Group’ – even Apple with the release of Safari Technology Preview 136 (link) has been updated to support manifest_version 3 and service_worker background scripts along with man other features (there appears to be a flurry of activity from Apple regrading the Webextensions API which increased the declarativeNetRequest filter rules from 50,000 to 150,000 (per extension, Adguard gets around it by treating each filter category like a seperate extension – I’m unsure whether there is a hard global limit like how Chrome has) however hopefully they’ll bring it inline with Chrome 89 at a later date (Google sets it to 300,000 global limit – limit is shared amongst all the extensions installed)).

Side note 1: The interesting part has been that the global static rule limit has been set to 300,000 with Chrome 89 however it appears that Google don’t want developers relying on a fixed number as they have said developers should use getAvailableStaticRuleCount to find out how many rules they have left. What that indicates to me is that we may see that limit rise in the future – I assume that’ll happen when they develop a more efficient way of dealing with large numbers of filters to ensure that there isn’t a performance hit. With that all being said, at the moment on Safari I have 256512 active filters through Adguard. Although I have heard people with must larger sets of rules I’d say in the long term the limit will be addressed through a combination of the limit being increased while optimising the filtering rules.

Side note 2: If you’re wanting something to offset the above pessimism then there is light at the end of the tunnel. I suggest you read through the minutes by the (link) many developers working at the organisations which contribute to the ‘WebExtensions Community Group’ because for all the doom and gloom in the tech media, there is working going on behind the scene. When it comes to Google fixing issues and you’re getting frustrated because it is ‘taking too long’ then there is always the possibility that the reason why it is taking longer than expect is because they developer is wanting to bounce ideas off other members to then all members of the ‘WebExtensions Community Group’ can agree on how something is implemented.

Side note 3: Here is some interesting reading: