4 ms·

I found this post highly editorialized. Here's the actual response if you want to understand the context, instead of simply seeing bits and pieces with a journa

by junar 7y ago

I found this post highly editorialized. Here's the actual response if you want to understand the context, instead of simply seeing bits and pieces with a journalist's spin. https://groups.google.com/a/chromium.org/forum/#!topic/chromium-extensions/veJy9uAwS00%5B1-25%5D https://groups.google.com/a/chromium.org/forum/#!topic/chrom... Also, the headline seems mostly incorrect. The gist of it, as I understand, is that Chrome is enforcing a migration from the webRequest API to a new declarativeNetRequest API. The latter API doesn't currently have all the capabilities of the former, which is important for context blocking extensions. However, features are still being added and the team states that they are interested in more feedback from extension developers.

mbrumlow 7y ago
And if those features happen to never be implemented? I really think it is a bad practice to force adoption of a new API that can't fulfill the same functions as the previous one. Nobody would be here talking about this if they just made the new API without breaking add blocking (useful add blocking), and then forced people to move. Even more so given that it looks really bad when your main goal is to serve people ads.
- CmdrKrool 7y ago
  > I really think it is a bad practice to force adoption of a new API that can't fulfill the same functions as the previous one. I agree, which incidentally is the reason I switched from Firefox to Chromium a couple years back as Mozilla dropped XUL extensions for their own development convenience, toward an ideal of cross-browser extension compatibility, and in hoping to win over Chrome users by making Firefox more alike in both looks and performance. How many of those motivations have changed, and do we know that Mozilla aren't actually going to follow suit with a similar restructuring of APIs some time after such changes have settled into and been normalized in Chrome?
kkarakk 7y ago
I'm tired of major corps doing this with their APIs, either the new API is a drop in replacement for the old API or you're doing shady shit in the guise of "it's coming! soonish~"

by junar 7y ago

mbrumlow 7y ago

And if those features happen to never be implemented? I really think it is a bad practice to force adoption of a new API that can't fulfill the same functions as the previous one. Nobody would be here talking about this if they just made the new API without breaking add blocking (useful add blocking), and then forced people to move. Even more so given that it looks really bad when your main goal is to serve people ads.

CmdrKrool 7y ago
> I really think it is a bad practice to force adoption of a new API that can't fulfill the same functions as the previous one. I agree, which incidentally is the reason I switched from Firefox to Chromium a couple years back as Mozilla dropped XUL extensions for their own development convenience, toward an ideal of cross-browser extension compatibility, and in hoping to win over Chrome users by making Firefox more alike in both looks and performance. How many of those motivations have changed, and do we know that Mozilla aren't actually going to follow suit with a similar restructuring of APIs some time after such changes have settled into and been normalized in Chrome?

kkarakk 7y ago

I'm tired of major corps doing this with their APIs, either the new API is a drop in replacement for the old API or you're doing shady shit in the guise of "it's coming! soonish~"