#Mozilla moving #Firefox #WebExtension development to manifest v3 is a mistake. That is a bad spec and I don't see myself getting my own add-ons updated for it.

I didn't like when Google decided unilaterally to ship that broken spec.

There is no advantage in it besides "we need to do what Chrome does".

This sucks.

I'm very glad I'm plotting my way out of being a developer because this web dev ecosystem sucks.

@soapdog Maintaining compatibility with Chromium *is* an advantage, though. It means more extensions will be developed for Firefox as it lessens the cost of support a minority platform.

@da after they formed the WebExtensions Community Working Group:

w3.org/community/webextensions

I expected that such changes and evolutions would go through a design process with all stakeholders, not simply copying google who is basically doing recent changers to curb ad blockers.

manifest v2 is already compatible with Chrome. There is no reason for them not to keep supporting v2.

Follow

@soapdog The WECG was formed after Mv3 had become the de facto standard. Mv3 isn’t about curbing ad blockers. Mv3 deprecates one overloaded and very powerful API that slows down every single request and breaks in unpredictable fashion if more than one extensions try to use it at the same time. The sky isn’t falling. Mv3 has many good changes in it including host permission control and promised-based APIs (Firefox have had this for years, but the change aligns Chromium and Firefox API behavior.)

· · Web · 1 · 0 · 0

@soapdog If Google wanted to kill ad blockers in Chromium, this wouldn’t be the move it made to make that happen. Google is removing a slow and troublesome API for a reason. Overall, it’s very good for the extension ecosystem that Safari, Chrome, Edge, and Firefox will be on the same page on all of this stuff for the first time.

@da thanks for sharing an insightful response. I will take a look at it again. Tbh I never felt like mv3 is a de facto standard. For me it feels rushed. I would like to have seen a more open and collaborative process.

I am on a very lonely boat with the couple other people who enjoy having more powerful APIs available, but I understand the implications.

One thing I don’t like is how they are changing backgrounds for example, but it is a small patch for most addons.

I will look at it again

@soapdog My own extensions will also stop working without webRequest. However, the API is overloaded and slows down every requests. So, I understand that they want it gone. It was a big mistake to add it in the first place. Background page versus service worker is just about switching long-lived processes to something that’s more optimized for running JavaScript without layout and rendering. I believe it reduces overhead, start up delays, and improves scheduling (unverified gut feeling on this last point.)

@da what I am doing with my main extension is making sure it is still useful outside a webextension context. This way I might eventually also offer it as a PWA with reduced feature set if needed.

I will try to convert it for v3 but will have a escape plan.

Sign in to participate in the conversation
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!