1. 11
  1.  

  2. 18

    When all browsers were finally coalescing into a unified API for WebExtensions, Google comes in and just throws in a whole new namespace with a new API… I’m really annoyed at this kind of behaviour.

    1. 6

      They’ve been talking about Manifest v3 being a breaking change for multiple years now. Moreover, there wasn’t a real unified API for webextensions, Mozilla’s APIs are promise based while Google’s v2 APIs are callback based. Yeah, you can polyfill the gap with a library but that’s still not really what you would call a unified API. There’s also a ton of APIs that Mozilla implements and Google doesn’t and Apple is happy to have its own set of discrepancies (I know there are some at least around the native messenger APIs, I don’t know if there are others elsewhere). So pretty standard for the web, really ¯_(ツ)_/¯.

      What really distresses me is that they’re not offering any way to execute code in the page’s context rather than in the content process. This is often required if you want to interact with JS-heavy pages and becoming harder each day because websites are adopting more-aggressive CSPs (which is a good thing, but prevents webextensions from doing their magic).

      1. 7

        A cynical view might be to say that’s intentional: they don’t want extensions monkeying with Google services in Google’s own browser.