11 ms·

Pausing Manifest V2 phase-out changes

256 points by ghostwords 4y ago

rx_tx 4y ago
This is for Manifest V2 (browser extension API that has been generating a lot of debate) and not some Mountain View office footprint expansion like I mistakenly thought out of context.
ghostwords 4y ago
Previous Google Chrome extensions Manifest V2 shutoff update thread: https://news.ycombinator.com/item?id=33012057 https://news.ycombinator.com/item?id=33012057
ranting-moth 4y ago
I was writing an extension a few weeks ago. I decided to go with MV3. Most of the examples and documentation said something like "this has been copied from the MV2 documents or example. It might not work." It was awful. I felt MV3 is really about limiting what the extensions can do. I ended up having it Firefox only and MV2. Probably works in Chrome too, but I wasn't going to waste time on it since it was about to be removed.
- zamadatix 4y ago
  MV3 has some changes that are genuinely good, even if those may feel inconvenient to develop for, mixed in with the genuinely bad. For FF you can get the best of both worlds though since their MV3 implementation isn’t removing the controversial deprecations/plans.
- modeless 4y ago
  Yeah the state of Chrome's extension API documentation is awful. It needs to be totally reorganized and partially rewritten. I'm hopeful that MDN will become a better resource as Firefox becomes more compatible with the APIs. It's already more helpful in some places.
  - joshka 4y ago
    Funny, I've been using the MDN docs and took a look at the Chrome docs today. Some of the conceptual info was easier to track on the Chrome docs where the Mozilla side seemed to jump too low level too quickly. Ideally, those docs should just be in one place so writing Chrome/Safari/Firefox extensions should just work.
    - eyelidlessness 4y ago
      > the Mozilla side seemed to jump too low level too quickly This is literally my only complaint about MDN, and it’s only a complaint when I’m in a hurry. The sprawling body of standards MDN documents are almost all fairly low level and intended as such, and MDN mostly does a good job of balancing the low level details with good boilerplate examples. I can’t say how this is for extensions on any version, but if the MDN docs continue apace I’d be surprised if they don’t at least adequately answer this “should” as shortly behind a stable spec as anyone could wish for. I wish XML-related tech was such a hot documentation commodity… guess I better contribute as I go :)
      - ctxc 4y ago
        Hey! What things related to xml are you working on? I for one went through the signing and stuff and it was pretty rough going.
        eyelidlessness 4y ago
        I maintain the Enketo[1] projects for ODK[2]. The latter is a little more flexible and stable on the XML front, but the former is currently in the position of using a lot of nonstandard XML tooling despite being well positioned to use existing browser tech, and at the same time may be better off migrating to many of the same abstractions ODK already uses. 1: https://github.com/enketo https://github.com/enketo 2: https://github.com/getodk https://github.com/getodk
  - iLoveOncall 4y ago
    All of Google's documentations are awful. I spent a few days on a pet project using the Google Sheets API and the official docs use a mix of 3 different versions of libraries, none of which are really up to date, and you have to guess which is the right one. They don't care about developers.
- HellsMaddy 4y ago
  I developed an extension[1] after the Chrome Store stopped accepting MV2, but before Firefox support for MV3 in stable. I had to write some custom build scripts to build the extension with MV2 for Firefox and MV3 for Chrome. Pretty annoying. [1]: https://github.com/b0o/aws-favicons-webextension https://github.com/b0o/aws-favicons-webextension
- joshka 4y ago
  I'm in a similar boat, wrote a MV2 plugin for firefox, started looking at MV3 got confused about which bits are going to be usable and which are not and when. Ends up being too difficult. From a extension creator perspective, it might be better to just pull all mention of MV3 on the MV2 pages until it's properly baked.
  - vdfs 4y ago
    FYI Firefox is ditching MV2 too, they are keeping web request blocking but they will deprecate v2
    - joshka 4y ago
      Yeah, it's in the nightly and going to GA Jan 23 according to the latest blog post on it.
    - Vinnl 4y ago
      > MV2 will continue to work. We have not made decisions about MV2 deprecation yet. We want to see what the response and adoption of MV3 is from the community next year and will then make decisions about the future based on that. https://blog.mozilla.org/addons/2022/10/31/begin-your-mv3-migration-by-implementing-new-features-today/#comment-227534 https://blog.mozilla.org/addons/2022/10/31/begin-your-mv3-mi...
      - vdfs 4y ago
        https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-firefox-recap-next-steps/ https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-fi... I guess they are following Chrome migration plan by delaying the inevitable
        Vinnl 4y ago
        I don't think that says anything about concrete plans for ditching MV2 yet?
- eshack94 4y ago
  > I felt MV3 is really about limiting what the extensions can do. You felt that way because that's exactly what it's about. It's about doing everything possible to increase ad revenue in the name of "increased security".
lapcat 4y ago
I knew this was coming. Google said that they're committed to allowing userscripts in MV3, but they haven't even started the implementation. They're still in the proposal phase. https://github.com/w3c/webextensions/issues/279 https://github.com/w3c/webextensions/issues/279
- vbezhenar 4y ago
  You can't insert tag into webpage? I'm confused.
  - lzaaz 4y ago
    Quite literally yes. It would've killed GreaseMonkey userscripts and such
    - vbezhenar 4y ago
      According to my little research you can insert script tags, but you can only use the scripts which are bundled inside the extension. It's still not clear to me what prevents this script to download external script using AJAX which will execute whatever user wants (e.g. some cloud userscript service). Also for power users it should not be a problem at all. Just create your own extension which is literally few simple files and put your userscripts inside that extension. Then load this extension from the chrome and voila.
      - oefrha 4y ago
        > It's still not clear to me what prevents this script to download external script using AJAX which will execute whatever user wants If you read the MV3 migration guide you’ll quickly realize why. CSP script-src is restricted to self, none, or localhost sources for all non-sandbox pages, content scripts included. https://developer.chrome.com/docs/extensions/mv3/mv3-migration/#content-security-policy https://developer.chrome.com/docs/extensions/mv3/mv3-migrati...
        4y ago
CitrusFruits 4y ago
This is a huge relief. The lack of Offscreen Documents API has been a huge hurdle for migrating to MV3 and has caused numerous headaches.
dang 4y ago
Related. Others? Feel the power of the Manifest v3 - https://news.ycombinator.com/item?id=33063619 https://news.ycombinator.com/item?id=33063619 - Oct 2022 (274 comments) Google postpones MV2 shutoff in Chrome stable to June 2023 - https://news.ycombinator.com/item?id=33012057 https://news.ycombinator.com/item?id=33012057 - Sept 2022 (283 comments) Manifest V3: The Ghostery Perspective (2021) - https://news.ycombinator.com/item?id=32983565 https://news.ycombinator.com/item?id=32983565 - Sept 2022 (5 comments) Manifest V3, webRequest, and ad blockers - https://news.ycombinator.com/item?id=32950199 https://news.ycombinator.com/item?id=32950199 - Sept 2022 (153 comments) uBlock Origin Lite: Description - https://news.ycombinator.com/item?id=32911640 https://news.ycombinator.com/item?id=32911640 - Sept 2022 (148 comments) Proxy Chrome extensions are not going to be usable in MV3 - https://news.ycombinator.com/item?id=32899846 https://news.ycombinator.com/item?id=32899846 - Sept 2022 (204 comments) Ad blockers struggle under Chrome's new rules - https://news.ycombinator.com/item?id=32764304 https://news.ycombinator.com/item?id=32764304 - Sept 2022 (3 comments) “UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3 - https://news.ycombinator.com/item?id=32754274 https://news.ycombinator.com/item?id=32754274 - Sept 2022 (255 comments) AdGuard publishes the first ad blocker built on Manifest V3 - https://news.ycombinator.com/item?id=32648131 https://news.ycombinator.com/item?id=32648131 - Aug 2022 (360 comments) Cannot read clipboard from service worker in a MV3 chrome extension (2020) - https://news.ycombinator.com/item?id=32622739 https://news.ycombinator.com/item?id=32622739 - Aug 2022 (51 comments) Tor Project – 'We are concerned about Google's plan to retire Manifest v2' - https://news.ycombinator.com/item?id=32608847 https://news.ycombinator.com/item?id=32608847 - Aug 2022 (4 comments) Chrome extension Manifest V3 migration tracker - https://news.ycombinator.com/item?id=31494944 https://news.ycombinator.com/item?id=31494944 - May 2022 (6 comments) Manifest v3 in Firefox: Recap and Next Steps - https://news.ycombinator.com/item?id=31425256 https://news.ycombinator.com/item?id=31425256 - May 2022 (168 comments) Ask HN: Will you keep using Chrome when manifest-v2 is sunset? - https://news.ycombinator.com/item?id=30589773 https://news.ycombinator.com/item?id=30589773 - March 2022 (5 comments) Google’s Manifest V3 still hurts privacy, security, and innovation - https://news.ycombinator.com/item?id=29555673 https://news.ycombinator.com/item?id=29555673 - Dec 2021 (2 comments) Google Nukes Ad-Blockers–Manifest V3 Is Coming - https://news.ycombinator.com/item?id=29522952 https://news.ycombinator.com/item?id=29522952 - Dec 2021 (6 comments) PSA: uBlock/AdBlocks on Chrome to lose function thanks to Manifestv3 - https://news.ycombinator.com/item?id=29521258 https://news.ycombinator.com/item?id=29521258 - Dec 2021 (315 comments) Chrome users beware: Manifest v3 is deceitful and threatening - https://news.ycombinator.com/item?id=29502439 https://news.ycombinator.com/item?id=29502439 - Dec 2021 (375 comments) Chrome phasing out Manifest v2 support from Jan 2022 - https://news.ycombinator.com/item?id=29410104 https://news.ycombinator.com/item?id=29410104 - Dec 2021 (33 comments) Google sets burial date for legacy Chrome Extensions, fears for ad-blockers grow - https://news.ycombinator.com/item?id=28680033 https://news.ycombinator.com/item?id=28680033 - Sept 2021 (386 comments) Manifest V2 Support Timeline - https://news.ycombinator.com/item?id=28645250 https://news.ycombinator.com/item?id=28645250 - Sept 2021 (2 comments) Manifest v3 Update - https://news.ycombinator.com/item?id=27305127 https://news.ycombinator.com/item?id=27305127 - May 2021 (93 comments) Microsoft Will Adopt Google Chrome's Controversial Manifest V3 in Edge - https://news.ycombinator.com/item?id=25445823 https://news.ycombinator.com/item?id=25445823 - Dec 2020 (4 comments) Manifest V3 now available on M88 Beta - https://news.ycombinator.com/item?id=25361535 https://news.ycombinator.com/item?id=25361535 - Dec 2020 (138 comments) Manifest V3 changes are now available to test in Microsoft Edge - https://news.ycombinator.com/item?id=24780055 https://news.ycombinator.com/item?id=24780055 - Oct 2020 (36 comments) Google Begins Testing Extension Manifest V3 in Chrome Canary - https://news.ycombinator.com/item?id=21503049 https://news.ycombinator.com/item?id=21503049 - Nov 2019 (436 comments) Mozilla’s Manifest v3 FAQ - https://news.ycombinator.com/item?id=20867720 https://news.ycombinator.com/item?id=20867720 - Sept 2019 (106 comments) Chrome extension manifest v3 proposal: comment from uBlock Origin author - https://news.ycombinator.com/item?id=20050173 https://news.ycombinator.com/item?id=20050173 - May 2019 (279 comments) Google to restrict modern ad blocking Chrome extensions to enterprise users - https://news.ycombinator.com/item?id=20044430 https://news.ycombinator.com/item?id=20044430 - May 2019 (877 comments) Chrome Extension Manifest V3 Could End UBlock Origin for Chrome - https://news.ycombinator.com/item?id=18976409 https://news.ycombinator.com/item?id=18976409 - Jan 2019 (4 comments) Chrome Extension Manifest V3 (draft) may end uBlock Origin - https://news.ycombinator.com/item?id=18971656 https://news.ycombinator.com/item?id=18971656 - Jan 2019 (3 comments)
mfrisbie 4y ago
What an unmitigated disaster. Anyone who has been following the MV3 transition saw this coming from a mile away. When I wrote the MV3 chapter for "Building Browser Extensions", it was nearly impossible to commit to any content because there was so little clarity or direction. I suppose Google gets a tiny bit of credit for not jamming MV3 through and leaving developers with the bill, but given the state of things, who has any confidence in what the future of browser extensions holds?
- eight_ender 4y ago
  I wont mention what company, but where I work we've spent about 6 months now with an entire dev team hammering their heads against a wall trying to port our extension to MV3, because the alternative was to lose it entirely at the deadline. Hacks, workarounds, bad docs, and lately, Google pops up to tell us OSD is kinda sorta a thing you can use, but clearly it's at a basically alpha level of maturity. This latest announcement might seem like a reprieve, but it's even worse than before for us, because now it's clear that OSD is a temporary measure, and now we have promises to fix the actual issues in the future. As a manager I have no idea how to proceed. Do we solider ahead with OSD like we planned? Wait for them to fix the core issues? We have so little trust in Google fixing things, and a great deal of confidence in them making things worse at this point. If we commit to OSD we might be looking at doing the same level of work again, when they fix the core issues and deprecate it. If we wait for core fixes, we might not get the work done before a nebulous future deadline that could drop on us at any moment. Google has caused us to burn an absolutely incredible amount of time and money with this. Believe me, we're are footing the bill, and have been for some time now.
- dmitriid 4y ago
  > I suppose Google gets a tiny bit of credit for not jamming MV3 through and leaving developers with the bill They will try again in a year, and there will be less opposition (because people get tired of fighting etc.), and this will happen
  - akiselev 4y ago
    Doesn’t matter. The only people who take Google seriously now are the people who took IBM seriously yesterday. Google isn’t the CIA or NSA. They don’t have that kind of staying power because they don’t have any guiding principle beyond profit (for better or for worse).
xnx 4y ago
Some of the most interesting announcements are made late on Fridays.
puffoflogic 4y ago
Translation: We already accomplished our goal of killing (efficient, effective) ad blockers and we really don't feel like doing the rest of the work. Have fun with the results!
DarkmSparks 4y ago
But really, the prospect of breaking support for the innumerable applications that use V2 and will never be updated seems to be the worst idea Ive seen in decades. I still struggle to believe it, but everytime I read something on this "V3 migration" that sounds like exactly what they plan.. This isnt like IE6 either, where every user was desperate for the apps they were forced to use to die, it seems the only people that really want this change is google. Apologies in advance if Im wrong, the only reason I care is I keep hearing "google plans to break lots of stuff with no clear need to do so."
- matheusmoreira 4y ago
  They're the only ones who want this change because they're the billion dollar advertising corporation and they want to kill ad blockers on Chrome. The more painful and costly it is for them, the better. Hopefully it will reduce Chrome market share too when other browsers refuse to deprecate the features uBlock Origin needs. Still not enough punishment for them.
  - defrost 4y ago
    > Still not enough punishment for them. Force them all to live as Winston Smith in rooms with wall sized screens that deliver unblockable ads and monitor their every action? ie. To eat their own dogfood.
    - matheusmoreira 4y ago
      Don't forget the high pitched noise when they try to close their eyes.
      - EdwardDiego 4y ago
        New on Wraith Babes, millions watched her glide through the Hot Shot curtain of dreams... ...Insufficent funds to skip...
  - tlogan 4y ago
cube00 4y ago
Locking the message so nobody can reply is a nice touch.
- chucky123 4y ago
  That's the Google way(tm)
- anaganisk 4y ago
  The removed the dislike button after some exec video of google got so many dislike.
  - postsantum 4y ago
    That was the video where Susan Wojcicki received a freedom of speech award from her mom
dessant 4y ago
The Chrome extensions team has been considerably more responsive to criticism since Simeon Vincent has become a Developer Advocate. It's important to see the perspective of developers who've been working with these APIs for years, and I'm glad that they are finally listening.
- lapcat 4y ago
  Vincent has been in that position for 4 years, so I'm not sure what you think has changed.
  - dessant 4y ago
    Before that we didn't have anyone to contact, and the Chrome extensions team definitely did not react to feedback in any meaningful way.
    - horsawlarway 4y ago
      I'm not really sure I agree with this - I've been doing extension development for about 12 years now, and I think communication used to be fine. Simply posting questions usually got meaningful feedback, and while the team certainly wasn't "taking advice" from the community at large, the manifest v2 space felt cohesive and generally well thought out. Things worked. Documentation was decent. Compatibility problems between Firefox/Chrome were small and documented. It was still possible to load extensions outside the stores. Extensions could do genuinely powerful things. Manifest v3... has been a complete fucking disgrace (and I say that as someone who was really, really trying to give Google the benefit of the doubt here early on, and someone who has personally ported my organization's extensions to MV3). It's poorly documented (all sorts of things in the docs are half-assed, scattered links to mv2 only pages, dead/broken links in the pages, docs that contradict other docs, completely undocumented features and capabilities, bad examples, examples that no longer build, etc). Basic features are literally not functional. We STILL to this day have repeated complaints from customers about the extension "dying" or "it stopped working" which I can fucking promise is this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1271154 https://bugs.chromium.org/p/chromium/issues/detail?id=127115... Which has been closed and opened several times (currently closed and is absolutely still happening). I still see this at least once a week in development. The service worker simply fucks off and stops doing anything at all (sitting there with "inactive" despite sending messages to it, or clicking the browser action). Permissions are still a freaking disgrace - trying to play nice with the permissions APIs gets your extension relegated way down the list. Extensions which just request "all_urls" get put right at the top of the extensions list when a user clicks the extensions menu, while those that properly ask for the active_tab permission get shoved way down and have a "access requested" tag in bold that actually seems scarier to users than the extensions that just fucking declare all_urls. Optional permissions, meanwhile, don't actually go away when you release them in chrome (why even have the fucking function call?) so you can't meaningfully display permissions status to users without tracking state yourself. And you sure as hell can't count on the state of a permission to indicate user preference on whether a feature should be active. Again - have to do all the tracking manually. Basically - The chromium team is fucking up HARD here, in my opinion. It's really starting to feel like the decent developers are gone (and I know a lot of them are) and the result is now the same as IE used to be - the browser is just a political tool to control competition. There's little cohesion, features & flows are broken at random and with no documentation. Issues are triaged superficially and then closed instead of resolved. Developers are ridiculed by the team for posting questions (jesus some of the responses around questions for declarativeNetRequest are fucking bad - especially given the shoddy state of the docs), or simply ignored. I'm pretty torn - I actually think the Edge port of chromium is better than chromium at this point - and if you'd told me 10 years ago that I would end up saying MS has a better browser, I would have laughed in your face. Meanwhile FF is just limping along, and Safari is absolutely neglected because apple makes all their money in the app store, so it's in their interests to have a shoddy browser from a feature perspective (they still do good work on performance and battery usage, at least). --- Long rant aside - I'm very disappointed in MV3. I tried hard to play along, and it's shite.
gnicholas 4y ago
This has been so frustrating. My company has two Chrome extensions, one of which we've been able to migrate and are just finishing up, and one of which we are blocked on because we're waiting on a dependency to be sorted out. Of course, we're not just on Chrome — we're also on Firefox. But our migrated extension doesn't work on Firefox, since they haven't fully figured out their transition plan. We're left with a gigantic mess that will be confusing to users (because our Chrome MV3 has significant changes to our freemium model, which made sense to implement during the manifest changeover). We'll have to explain to our FF users that they still have the old version, but the new version is only on Chrome. But for our other extension, everyone's on the old version. What a mess.
- CatWChainsaw 4y ago
  I thought Firefox had no MV3 plans. Why does that extension require a transition?
  - gnicholas 4y ago
    The issue is that when the MV3 transition was announced, we decided to revamp our freemium structure. We've now completed that for our MV3 extension, but that only runs on Chrome. Our Firefox version is still running the MV2 extension, which is perfectly functional but which uses our old freemium model. We are going to have to explain to our Firefox users why the freemium structure (free use on X websites forever) differs from the freemium structure described on our Chrome extension, website, etc. (free use on all websites for Y days).
spritefs 4y ago
Let me get this straight: google is removing support for blocking webRequest API, but keeping support for non-blocking webRequest API? How is this supposed to benefit privacy if the non-blocking API is still supported?
- teraflop 4y ago
  The "blocking" and "non-blocking" APIs do completely different things. With the old API (webRequest), Chrome calls an extension's event handlers before every network request, and uses the result of the handler to decide whether to filter the request. This requires Chrome itself to block With the new API (declarativeNetRequest), an extension sends a list of rules (i.e. URL patterns) to Chrome, and each rule specifies a static instruction that says how requests matching that pattern should be handled (for instance, being blocked, upgraded from HTTP to HTTPS, or redirected). So Chrome can use its own optimized lookup procedure and doesn't have to block waiting for extension code to complete, which might take arbitrarily long. The privacy advantage is that the extension can tell Chrome how to handle network requests (in a much more limited way than before) but can't actually gain any information about what requests the user is making. But that's only part of the justification. The Chrome developers have stated in the past that they believe slow extensions using the old webRequest API are causing general browser performance problems (by doing lots of blocking computation on every request) and making it seem like it was Chrome's fault.
  - atesti 4y ago
    But don't they keep the original webRequest api in a way where it does not block and where an extension can observer all the traffice, do all the spying, but just cannot block requests?
    - gsnedders 4y ago
      It's a separate permission, I believe.
    - somehnacct3757 4y ago
      The extension would need both the all_urls and webRequest permissions to do this, since you can only spy on requests to origins your extension has a host permission for. The review team discourages all_urls permissions and scrutinizes them more, so theoretically getting a spy onto the store with the right permission combo is hard. If you trust the review team. Note that these regulations were established for MV2, and MV3 doesn't do anything new to address this. So there's still no benefit to MV3 on this topic. As far as I can tell, and I work with these APIs for a living, the privacy claims of MV3 are bogus.
svnpenn 4y ago
> This conversation is locked Says all you need to know. They are going to shove this down people's throats, whether they like it or not. Maybe not now, but it's coming. It's kind of disgusting how they talk about this change so matter of fact, as if Chrome is the only choice that people have.
- userbinator 4y ago
  They've already lobbied plenty of web developers into making sites Chrome-only. It certainly shows how powerful their propaganda is.
  - rs_rs_rs_rs_rs 4y ago
    >They've already lobbied plenty of web developers into making sites Chrome-only No they didn't, why do you lie like that?
    - xmprt 4y ago
      I won't make as strong a claim that they've lobbied developers to make sites Chrome-only, but they've created a lot of tools for developers to check how performant their website is and how SEO friendly it is. Most of the time that's based on Google's metrics which work best on Google's browser and search.
      - rs_rs_rs_rs_rs 4y ago
        >Most of the time that's based on Google's metrics which work best on Google's browser And which ones are that? Time to first byte, first content paint, render blocking resources?
      - hoten 4y ago
        The web performance metrics absolutely are not specific to Chrome, what makes you think that?
    - dmitriid 4y ago
jerrygoyal 4y ago
The story: They announced mv2 will phase out. Their initial plan for mv3 was to cripple remote code execution and network requests intercept api for their own good. They didn't anticipate this much backlash from the community. Now they've to reintroduce those capabilities making it same to mv2 :| Circus.
2Gkashmiri 4y ago
booo..... "but muh brave wont be supporting it".... the way to signal google that they are not doing a good thing is by replacing chrome/chromium with firefox. switching from chrome to opera/brave is doing the same thing. sure, firefox is not helping their cause because of their CEO salivating at google revenue but even then, they have committed to supporting UBO, something that goes on to say a lot more about the ethics behind firefox as opposed to chrome

256 points by ghostwords 4y ago

This is for Manifest V2 (browser extension API that has been generating a lot of debate) and not some Mountain View office footprint expansion like I mistakenly thought out of context.

ghostwords 4y ago

Previous Google Chrome extensions Manifest V2 shutoff update thread: https://news.ycombinator.com/item?id=33012057 https://news.ycombinator.com/item?id=33012057

ranting-moth 4y ago

I was writing an extension a few weeks ago. I decided to go with MV3. Most of the examples and documentation said something like "this has been copied from the MV2 documents or example. It might not work." It was awful. I felt MV3 is really about limiting what the extensions can do. I ended up having it Firefox only and MV2. Probably works in Chrome too, but I wasn't going to waste time on it since it was about to be removed.

zamadatix 4y ago
MV3 has some changes that are genuinely good, even if those may feel inconvenient to develop for, mixed in with the genuinely bad. For FF you can get the best of both worlds though since their MV3 implementation isn’t removing the controversial deprecations/plans.
modeless 4y ago
Yeah the state of Chrome's extension API documentation is awful. It needs to be totally reorganized and partially rewritten. I'm hopeful that MDN will become a better resource as Firefox becomes more compatible with the APIs. It's already more helpful in some places.
- joshka 4y ago
  Funny, I've been using the MDN docs and took a look at the Chrome docs today. Some of the conceptual info was easier to track on the Chrome docs where the Mozilla side seemed to jump too low level too quickly. Ideally, those docs should just be in one place so writing Chrome/Safari/Firefox extensions should just work.
  - eyelidlessness 4y ago
    > the Mozilla side seemed to jump too low level too quickly This is literally my only complaint about MDN, and it’s only a complaint when I’m in a hurry. The sprawling body of standards MDN documents are almost all fairly low level and intended as such, and MDN mostly does a good job of balancing the low level details with good boilerplate examples. I can’t say how this is for extensions on any version, but if the MDN docs continue apace I’d be surprised if they don’t at least adequately answer this “should” as shortly behind a stable spec as anyone could wish for. I wish XML-related tech was such a hot documentation commodity… guess I better contribute as I go :)
    - ctxc 4y ago
      Hey! What things related to xml are you working on? I for one went through the signing and stuff and it was pretty rough going.
      - eyelidlessness 4y ago
        I maintain the Enketo[1] projects for ODK[2]. The latter is a little more flexible and stable on the XML front, but the former is currently in the position of using a lot of nonstandard XML tooling despite being well positioned to use existing browser tech, and at the same time may be better off migrating to many of the same abstractions ODK already uses. 1: https://github.com/enketo https://github.com/enketo 2: https://github.com/getodk https://github.com/getodk
- iLoveOncall 4y ago
  All of Google's documentations are awful. I spent a few days on a pet project using the Google Sheets API and the official docs use a mix of 3 different versions of libraries, none of which are really up to date, and you have to guess which is the right one. They don't care about developers.
HellsMaddy 4y ago
I developed an extension[1] after the Chrome Store stopped accepting MV2, but before Firefox support for MV3 in stable. I had to write some custom build scripts to build the extension with MV2 for Firefox and MV3 for Chrome. Pretty annoying. [1]: https://github.com/b0o/aws-favicons-webextension https://github.com/b0o/aws-favicons-webextension
joshka 4y ago
I'm in a similar boat, wrote a MV2 plugin for firefox, started looking at MV3 got confused about which bits are going to be usable and which are not and when. Ends up being too difficult. From a extension creator perspective, it might be better to just pull all mention of MV3 on the MV2 pages until it's properly baked.
- vdfs 4y ago
  FYI Firefox is ditching MV2 too, they are keeping web request blocking but they will deprecate v2
  - joshka 4y ago
    Yeah, it's in the nightly and going to GA Jan 23 according to the latest blog post on it.
  - Vinnl 4y ago
    > MV2 will continue to work. We have not made decisions about MV2 deprecation yet. We want to see what the response and adoption of MV3 is from the community next year and will then make decisions about the future based on that. https://blog.mozilla.org/addons/2022/10/31/begin-your-mv3-migration-by-implementing-new-features-today/#comment-227534 https://blog.mozilla.org/addons/2022/10/31/begin-your-mv3-mi...
    - vdfs 4y ago
      https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-firefox-recap-next-steps/ https://blog.mozilla.org/addons/2022/05/18/manifest-v3-in-fi... I guess they are following Chrome migration plan by delaying the inevitable
      - Vinnl 4y ago
        I don't think that says anything about concrete plans for ditching MV2 yet?
eshack94 4y ago
> I felt MV3 is really about limiting what the extensions can do. You felt that way because that's exactly what it's about. It's about doing everything possible to increase ad revenue in the name of "increased security".

lapcat 4y ago

I knew this was coming. Google said that they're committed to allowing userscripts in MV3, but they haven't even started the implementation. They're still in the proposal phase. https://github.com/w3c/webextensions/issues/279 https://github.com/w3c/webextensions/issues/279

vbezhenar 4y ago
You can't insert tag into webpage? I'm confused.
- lzaaz 4y ago
  Quite literally yes. It would've killed GreaseMonkey userscripts and such
  - vbezhenar 4y ago
    According to my little research you can insert script tags, but you can only use the scripts which are bundled inside the extension. It's still not clear to me what prevents this script to download external script using AJAX which will execute whatever user wants (e.g. some cloud userscript service). Also for power users it should not be a problem at all. Just create your own extension which is literally few simple files and put your userscripts inside that extension. Then load this extension from the chrome and voila.
    - oefrha 4y ago
      > It's still not clear to me what prevents this script to download external script using AJAX which will execute whatever user wants If you read the MV3 migration guide you’ll quickly realize why. CSP script-src is restricted to self, none, or localhost sources for all non-sandbox pages, content scripts included. https://developer.chrome.com/docs/extensions/mv3/mv3-migration/#content-security-policy https://developer.chrome.com/docs/extensions/mv3/mv3-migrati...
      - 4y ago

CitrusFruits 4y ago

This is a huge relief. The lack of Offscreen Documents API has been a huge hurdle for migrating to MV3 and has caused numerous headaches.

dang 4y ago

Related. Others? Feel the power of the Manifest v3 - https://news.ycombinator.com/item?id=33063619 https://news.ycombinator.com/item?id=33063619 - Oct 2022 (274 comments) Google postpones MV2 shutoff in Chrome stable to June 2023 - https://news.ycombinator.com/item?id=33012057 https://news.ycombinator.com/item?id=33012057 - Sept 2022 (283 comments) Manifest V3: The Ghostery Perspective (2021) - https://news.ycombinator.com/item?id=32983565 https://news.ycombinator.com/item?id=32983565 - Sept 2022 (5 comments) Manifest V3, webRequest, and ad blockers - https://news.ycombinator.com/item?id=32950199 https://news.ycombinator.com/item?id=32950199 - Sept 2022 (153 comments) uBlock Origin Lite: Description - https://news.ycombinator.com/item?id=32911640 https://news.ycombinator.com/item?id=32911640 - Sept 2022 (148 comments) Proxy Chrome extensions are not going to be usable in MV3 - https://news.ycombinator.com/item?id=32899846 https://news.ycombinator.com/item?id=32899846 - Sept 2022 (204 comments) Ad blockers struggle under Chrome's new rules - https://news.ycombinator.com/item?id=32764304 https://news.ycombinator.com/item?id=32764304 - Sept 2022 (3 comments) “UBO Minus (MV3)” – An Experimental uBlock Origin Build for Manifest V3 - https://news.ycombinator.com/item?id=32754274 https://news.ycombinator.com/item?id=32754274 - Sept 2022 (255 comments) AdGuard publishes the first ad blocker built on Manifest V3 - https://news.ycombinator.com/item?id=32648131 https://news.ycombinator.com/item?id=32648131 - Aug 2022 (360 comments) Cannot read clipboard from service worker in a MV3 chrome extension (2020) - https://news.ycombinator.com/item?id=32622739 https://news.ycombinator.com/item?id=32622739 - Aug 2022 (51 comments) Tor Project – 'We are concerned about Google's plan to retire Manifest v2' - https://news.ycombinator.com/item?id=32608847 https://news.ycombinator.com/item?id=32608847 - Aug 2022 (4 comments) Chrome extension Manifest V3 migration tracker - https://news.ycombinator.com/item?id=31494944 https://news.ycombinator.com/item?id=31494944 - May 2022 (6 comments) Manifest v3 in Firefox: Recap and Next Steps - https://news.ycombinator.com/item?id=31425256 https://news.ycombinator.com/item?id=31425256 - May 2022 (168 comments) Ask HN: Will you keep using Chrome when manifest-v2 is sunset? - https://news.ycombinator.com/item?id=30589773 https://news.ycombinator.com/item?id=30589773 - March 2022 (5 comments) Google’s Manifest V3 still hurts privacy, security, and innovation - https://news.ycombinator.com/item?id=29555673 https://news.ycombinator.com/item?id=29555673 - Dec 2021 (2 comments) Google Nukes Ad-Blockers–Manifest V3 Is Coming - https://news.ycombinator.com/item?id=29522952 https://news.ycombinator.com/item?id=29522952 - Dec 2021 (6 comments) PSA: uBlock/AdBlocks on Chrome to lose function thanks to Manifestv3 - https://news.ycombinator.com/item?id=29521258 https://news.ycombinator.com/item?id=29521258 - Dec 2021 (315 comments) Chrome users beware: Manifest v3 is deceitful and threatening - https://news.ycombinator.com/item?id=29502439 https://news.ycombinator.com/item?id=29502439 - Dec 2021 (375 comments) Chrome phasing out Manifest v2 support from Jan 2022 - https://news.ycombinator.com/item?id=29410104 https://news.ycombinator.com/item?id=29410104 - Dec 2021 (33 comments) Google sets burial date for legacy Chrome Extensions, fears for ad-blockers grow - https://news.ycombinator.com/item?id=28680033 https://news.ycombinator.com/item?id=28680033 - Sept 2021 (386 comments) Manifest V2 Support Timeline - https://news.ycombinator.com/item?id=28645250 https://news.ycombinator.com/item?id=28645250 - Sept 2021 (2 comments) Manifest v3 Update - https://news.ycombinator.com/item?id=27305127 https://news.ycombinator.com/item?id=27305127 - May 2021 (93 comments) Microsoft Will Adopt Google Chrome's Controversial Manifest V3 in Edge - https://news.ycombinator.com/item?id=25445823 https://news.ycombinator.com/item?id=25445823 - Dec 2020 (4 comments) Manifest V3 now available on M88 Beta - https://news.ycombinator.com/item?id=25361535 https://news.ycombinator.com/item?id=25361535 - Dec 2020 (138 comments) Manifest V3 changes are now available to test in Microsoft Edge - https://news.ycombinator.com/item?id=24780055 https://news.ycombinator.com/item?id=24780055 - Oct 2020 (36 comments) Google Begins Testing Extension Manifest V3 in Chrome Canary - https://news.ycombinator.com/item?id=21503049 https://news.ycombinator.com/item?id=21503049 - Nov 2019 (436 comments) Mozilla’s Manifest v3 FAQ - https://news.ycombinator.com/item?id=20867720 https://news.ycombinator.com/item?id=20867720 - Sept 2019 (106 comments) Chrome extension manifest v3 proposal: comment from uBlock Origin author - https://news.ycombinator.com/item?id=20050173 https://news.ycombinator.com/item?id=20050173 - May 2019 (279 comments) Google to restrict modern ad blocking Chrome extensions to enterprise users - https://news.ycombinator.com/item?id=20044430 https://news.ycombinator.com/item?id=20044430 - May 2019 (877 comments) Chrome Extension Manifest V3 Could End UBlock Origin for Chrome - https://news.ycombinator.com/item?id=18976409 https://news.ycombinator.com/item?id=18976409 - Jan 2019 (4 comments) Chrome Extension Manifest V3 (draft) may end uBlock Origin - https://news.ycombinator.com/item?id=18971656 https://news.ycombinator.com/item?id=18971656 - Jan 2019 (3 comments)

mfrisbie 4y ago

What an unmitigated disaster. Anyone who has been following the MV3 transition saw this coming from a mile away. When I wrote the MV3 chapter for "Building Browser Extensions", it was nearly impossible to commit to any content because there was so little clarity or direction. I suppose Google gets a tiny bit of credit for not jamming MV3 through and leaving developers with the bill, but given the state of things, who has any confidence in what the future of browser extensions holds?

eight_ender 4y ago
I wont mention what company, but where I work we've spent about 6 months now with an entire dev team hammering their heads against a wall trying to port our extension to MV3, because the alternative was to lose it entirely at the deadline. Hacks, workarounds, bad docs, and lately, Google pops up to tell us OSD is kinda sorta a thing you can use, but clearly it's at a basically alpha level of maturity. This latest announcement might seem like a reprieve, but it's even worse than before for us, because now it's clear that OSD is a temporary measure, and now we have promises to fix the actual issues in the future. As a manager I have no idea how to proceed. Do we solider ahead with OSD like we planned? Wait for them to fix the core issues? We have so little trust in Google fixing things, and a great deal of confidence in them making things worse at this point. If we commit to OSD we might be looking at doing the same level of work again, when they fix the core issues and deprecate it. If we wait for core fixes, we might not get the work done before a nebulous future deadline that could drop on us at any moment. Google has caused us to burn an absolutely incredible amount of time and money with this. Believe me, we're are footing the bill, and have been for some time now.
dmitriid 4y ago
> I suppose Google gets a tiny bit of credit for not jamming MV3 through and leaving developers with the bill They will try again in a year, and there will be less opposition (because people get tired of fighting etc.), and this will happen
- akiselev 4y ago
  Doesn’t matter. The only people who take Google seriously now are the people who took IBM seriously yesterday. Google isn’t the CIA or NSA. They don’t have that kind of staying power because they don’t have any guiding principle beyond profit (for better or for worse).

xnx 4y ago

Some of the most interesting announcements are made late on Fridays.

puffoflogic 4y ago

Translation: We already accomplished our goal of killing (efficient, effective) ad blockers and we really don't feel like doing the rest of the work. Have fun with the results!

DarkmSparks 4y ago

But really, the prospect of breaking support for the innumerable applications that use V2 and will never be updated seems to be the worst idea Ive seen in decades. I still struggle to believe it, but everytime I read something on this "V3 migration" that sounds like exactly what they plan.. This isnt like IE6 either, where every user was desperate for the apps they were forced to use to die, it seems the only people that really want this change is google. Apologies in advance if Im wrong, the only reason I care is I keep hearing "google plans to break lots of stuff with no clear need to do so."

matheusmoreira 4y ago
They're the only ones who want this change because they're the billion dollar advertising corporation and they want to kill ad blockers on Chrome. The more painful and costly it is for them, the better. Hopefully it will reduce Chrome market share too when other browsers refuse to deprecate the features uBlock Origin needs. Still not enough punishment for them.
- defrost 4y ago
  > Still not enough punishment for them. Force them all to live as Winston Smith in rooms with wall sized screens that deliver unblockable ads and monitor their every action? ie. To eat their own dogfood.
  - matheusmoreira 4y ago
    Don't forget the high pitched noise when they try to close their eyes.
    - EdwardDiego 4y ago
      New on Wraith Babes, millions watched her glide through the Hot Shot curtain of dreams... ...Insufficent funds to skip...
- tlogan 4y ago

cube00 4y ago

Locking the message so nobody can reply is a nice touch.

chucky123 4y ago
That's the Google way(tm)
anaganisk 4y ago
The removed the dislike button after some exec video of google got so many dislike.
- postsantum 4y ago
  That was the video where Susan Wojcicki received a freedom of speech award from her mom

dessant 4y ago

The Chrome extensions team has been considerably more responsive to criticism since Simeon Vincent has become a Developer Advocate. It's important to see the perspective of developers who've been working with these APIs for years, and I'm glad that they are finally listening.

lapcat 4y ago
Vincent has been in that position for 4 years, so I'm not sure what you think has changed.
- dessant 4y ago
  Before that we didn't have anyone to contact, and the Chrome extensions team definitely did not react to feedback in any meaningful way.
  - horsawlarway 4y ago
    I'm not really sure I agree with this - I've been doing extension development for about 12 years now, and I think communication used to be fine. Simply posting questions usually got meaningful feedback, and while the team certainly wasn't "taking advice" from the community at large, the manifest v2 space felt cohesive and generally well thought out. Things worked. Documentation was decent. Compatibility problems between Firefox/Chrome were small and documented. It was still possible to load extensions outside the stores. Extensions could do genuinely powerful things. Manifest v3... has been a complete fucking disgrace (and I say that as someone who was really, really trying to give Google the benefit of the doubt here early on, and someone who has personally ported my organization's extensions to MV3). It's poorly documented (all sorts of things in the docs are half-assed, scattered links to mv2 only pages, dead/broken links in the pages, docs that contradict other docs, completely undocumented features and capabilities, bad examples, examples that no longer build, etc). Basic features are literally not functional. We STILL to this day have repeated complaints from customers about the extension "dying" or "it stopped working" which I can fucking promise is this issue: https://bugs.chromium.org/p/chromium/issues/detail?id=1271154 https://bugs.chromium.org/p/chromium/issues/detail?id=127115... Which has been closed and opened several times (currently closed and is absolutely still happening). I still see this at least once a week in development. The service worker simply fucks off and stops doing anything at all (sitting there with "inactive" despite sending messages to it, or clicking the browser action). Permissions are still a freaking disgrace - trying to play nice with the permissions APIs gets your extension relegated way down the list. Extensions which just request "all_urls" get put right at the top of the extensions list when a user clicks the extensions menu, while those that properly ask for the active_tab permission get shoved way down and have a "access requested" tag in bold that actually seems scarier to users than the extensions that just fucking declare all_urls. Optional permissions, meanwhile, don't actually go away when you release them in chrome (why even have the fucking function call?) so you can't meaningfully display permissions status to users without tracking state yourself. And you sure as hell can't count on the state of a permission to indicate user preference on whether a feature should be active. Again - have to do all the tracking manually. Basically - The chromium team is fucking up HARD here, in my opinion. It's really starting to feel like the decent developers are gone (and I know a lot of them are) and the result is now the same as IE used to be - the browser is just a political tool to control competition. There's little cohesion, features & flows are broken at random and with no documentation. Issues are triaged superficially and then closed instead of resolved. Developers are ridiculed by the team for posting questions (jesus some of the responses around questions for declarativeNetRequest are fucking bad - especially given the shoddy state of the docs), or simply ignored. I'm pretty torn - I actually think the Edge port of chromium is better than chromium at this point - and if you'd told me 10 years ago that I would end up saying MS has a better browser, I would have laughed in your face. Meanwhile FF is just limping along, and Safari is absolutely neglected because apple makes all their money in the app store, so it's in their interests to have a shoddy browser from a feature perspective (they still do good work on performance and battery usage, at least). --- Long rant aside - I'm very disappointed in MV3. I tried hard to play along, and it's shite.

gnicholas 4y ago

This has been so frustrating. My company has two Chrome extensions, one of which we've been able to migrate and are just finishing up, and one of which we are blocked on because we're waiting on a dependency to be sorted out. Of course, we're not just on Chrome — we're also on Firefox. But our migrated extension doesn't work on Firefox, since they haven't fully figured out their transition plan. We're left with a gigantic mess that will be confusing to users (because our Chrome MV3 has significant changes to our freemium model, which made sense to implement during the manifest changeover). We'll have to explain to our FF users that they still have the old version, but the new version is only on Chrome. But for our other extension, everyone's on the old version. What a mess.

CatWChainsaw 4y ago
I thought Firefox had no MV3 plans. Why does that extension require a transition?
- gnicholas 4y ago
  The issue is that when the MV3 transition was announced, we decided to revamp our freemium structure. We've now completed that for our MV3 extension, but that only runs on Chrome. Our Firefox version is still running the MV2 extension, which is perfectly functional but which uses our old freemium model. We are going to have to explain to our Firefox users why the freemium structure (free use on X websites forever) differs from the freemium structure described on our Chrome extension, website, etc. (free use on all websites for Y days).

spritefs 4y ago

Let me get this straight: google is removing support for blocking webRequest API, but keeping support for non-blocking webRequest API? How is this supposed to benefit privacy if the non-blocking API is still supported?

teraflop 4y ago
The "blocking" and "non-blocking" APIs do completely different things. With the old API (webRequest), Chrome calls an extension's event handlers before every network request, and uses the result of the handler to decide whether to filter the request. This requires Chrome itself to block With the new API (declarativeNetRequest), an extension sends a list of rules (i.e. URL patterns) to Chrome, and each rule specifies a static instruction that says how requests matching that pattern should be handled (for instance, being blocked, upgraded from HTTP to HTTPS, or redirected). So Chrome can use its own optimized lookup procedure and doesn't have to block waiting for extension code to complete, which might take arbitrarily long. The privacy advantage is that the extension can tell Chrome how to handle network requests (in a much more limited way than before) but can't actually gain any information about what requests the user is making. But that's only part of the justification. The Chrome developers have stated in the past that they believe slow extensions using the old webRequest API are causing general browser performance problems (by doing lots of blocking computation on every request) and making it seem like it was Chrome's fault.
- atesti 4y ago
  But don't they keep the original webRequest api in a way where it does not block and where an extension can observer all the traffice, do all the spying, but just cannot block requests?
  - gsnedders 4y ago
    It's a separate permission, I believe.
  - somehnacct3757 4y ago
    The extension would need both the all_urls and webRequest permissions to do this, since you can only spy on requests to origins your extension has a host permission for. The review team discourages all_urls permissions and scrutinizes them more, so theoretically getting a spy onto the store with the right permission combo is hard. If you trust the review team. Note that these regulations were established for MV2, and MV3 doesn't do anything new to address this. So there's still no benefit to MV3 on this topic. As far as I can tell, and I work with these APIs for a living, the privacy claims of MV3 are bogus.

svnpenn 4y ago

> This conversation is locked Says all you need to know. They are going to shove this down people's throats, whether they like it or not. Maybe not now, but it's coming. It's kind of disgusting how they talk about this change so matter of fact, as if Chrome is the only choice that people have.

userbinator 4y ago
They've already lobbied plenty of web developers into making sites Chrome-only. It certainly shows how powerful their propaganda is.
- rs_rs_rs_rs_rs 4y ago
  >They've already lobbied plenty of web developers into making sites Chrome-only No they didn't, why do you lie like that?
  - xmprt 4y ago
    I won't make as strong a claim that they've lobbied developers to make sites Chrome-only, but they've created a lot of tools for developers to check how performant their website is and how SEO friendly it is. Most of the time that's based on Google's metrics which work best on Google's browser and search.
    - rs_rs_rs_rs_rs 4y ago
      >Most of the time that's based on Google's metrics which work best on Google's browser And which ones are that? Time to first byte, first content paint, render blocking resources?
    - hoten 4y ago
      The web performance metrics absolutely are not specific to Chrome, what makes you think that?
  - dmitriid 4y ago

jerrygoyal 4y ago

The story: They announced mv2 will phase out. Their initial plan for mv3 was to cripple remote code execution and network requests intercept api for their own good. They didn't anticipate this much backlash from the community. Now they've to reintroduce those capabilities making it same to mv2 :| Circus.

2Gkashmiri 4y ago

booo..... "but muh brave wont be supporting it".... the way to signal google that they are not doing a good thing is by replacing chrome/chromium with firefox. switching from chrome to opera/brave is doing the same thing. sure, firefox is not helping their cause because of their CEO salivating at google revenue but even then, they have committed to supporting UBO, something that goes on to say a lot more about the ethics behind firefox as opposed to chrome