While it wasn't the first example of this, I think Web Audio set the standard for this pattern - individual Chrome contributors making their best effort to design and implement a cool API, but then the org's scheduling and priorities result in it shipping before it's remotely ready and before other browser vendors have meaningfully contributed to the process. This early ship date combined with Google's market power results in applications building on top of these immature APIs, which means that other vendors have no choice but to implement and ship absolute garbage.
Web Audio is a great example because they kicked that steaming pile out the door in order to enable (Chrome-only, naturally) web ports of things like Angry Birds, even though in practice that API was barely usable for anything and had all sorts of undesirable characteristics that still aren't completely fixed nearly a decade later. At the time Mozilla was working on a design and implementation for an API that was actually good, but Google's unilateral move killed any chance of a good solution being shipped by multiple vendors.
Other Chrome-only APIs have been similar stories, though at least Native Client/Pepper - probably the worst example - failed because the doomed design and implementation made it impossible for it to even hit their own production targets and drove app developers (like Unity) away.
In some cases you can meaningfully argue that other vendors are just dragging their feet - Safari being the main example, where they simply have been years late to ship useful things that both FF and Chrome had - but in practice nobody else has the massive development resources Google has to waste on dead-end trash APIs and nobody wants to pay the cost of implementing something they'll have to throw out a year later with the knowledge that websites won't support their browser anyway.
The meaningful security/privacy concerns Apple and Mozilla use to reject new Google APIs are also a good example, because Google has the resources to just address these security issues via brute force. They can unilaterally deprecate an existing API and break tons of websites (Web Audio, video, etc) or just ship something busted and rapidly rework it to try and paper over the consequences (WebMidi etc being used for fingerprinting...)
In my time working on the nacl (then WebAssembly) team it became clear to me that most of the devs there weren't acting on malicious motives, the overall structure and priorities of Google as a whole just produced bad outcomes. Sadly with their de-facto monopoly there's no pressures to fix that.