This is particularly amusing considering Google's extreme lack of v3 documentation. Their samples and examples Github, for example, has only 2 examples, iirc. They also introduce a lot of silliness like the inability to nest content scripts within folders.
Not to mention all the limitations of the Chrome browser. The continuous difference between console.log and console.dir. The former only shows you a very limited view of JS objects while the latter is what Firefox uses as the default for console.log - a full view of the object you want inspected. Then there's the inability to edit and resend network requests. The only workaround is to copy the request as a fetch request, dump it into the console or snippets, re-edit it there, and then send it through the console. Of course you'd have to parse the response in the console too instead of being able to see it in devtools.
And then there's Chrome's complete lack of proper proxy support. You could start the browser with command line flags in order to enable a SOCKS5 proxy, for example, but that requires you to close your existing browser session and open a new one.
Finally, how is it that we have nearly exact dates (2022-01-17 and sometime in January 2023) for V2 sunsetting but the dates for implementation of actual features needed to migrate away from V2 have no solid expectation date? Isn't that putting the cart before the horse? From the article:
"In the coming months, we'll also be launching support for dynamically configurable content scripts and an in-memory storage option, among other new capabilities."
"In the coming months"? The v2 sunset date is just a few months away! Why not ensure that the current feature set is fully functional and adequate to replace v2 before blocking v2 extension submissions?
It's interesting that you mention Chrome’s silliness when I find Firefox’ dev tools to be severely lacking, especially for WebExtensions. Examples include:
- complete inability to run code from the console into the content script context
- content script errors are not shown in the console, you have to open a separate Browser Console
- overall buggy dev tools (I don't remember anymore because I stopped using them a long time ago)
I guess every browser lacks something, it's just that we notice when we compare "my browser" to the next one.
Yeah each one has pros and cons. However if your doing POST and GET requests (Or monitoring network traffic in general) Firefox is much much better than Chrome!
Not to mention all the limitations of the Chrome browser. The continuous difference between console.log and console.dir. The former only shows you a very limited view of JS objects while the latter is what Firefox uses as the default for console.log - a full view of the object you want inspected. Then there's the inability to edit and resend network requests. The only workaround is to copy the request as a fetch request, dump it into the console or snippets, re-edit it there, and then send it through the console. Of course you'd have to parse the response in the console too instead of being able to see it in devtools.
And then there's Chrome's complete lack of proper proxy support. You could start the browser with command line flags in order to enable a SOCKS5 proxy, for example, but that requires you to close your existing browser session and open a new one.
Finally, how is it that we have nearly exact dates (2022-01-17 and sometime in January 2023) for V2 sunsetting but the dates for implementation of actual features needed to migrate away from V2 have no solid expectation date? Isn't that putting the cart before the horse? From the article:
"In the coming months, we'll also be launching support for dynamically configurable content scripts and an in-memory storage option, among other new capabilities."
"In the coming months"? The v2 sunset date is just a few months away! Why not ensure that the current feature set is fully functional and adequate to replace v2 before blocking v2 extension submissions?