FYI it's behind a feature flag (aka experiment). Just in case you rarely use experiments in DevTools:
DevTools -> Settings (cog, top right) -> Experiments -> Search for "Protocol Monitor" -> Check the checkbox
nicoburns 5 days ago [-]
CDP is a good exmaple of why the ecosystem has converged around Chrome and not Firefox. CDP has:
- Full documentation
- A stable API
- Tooling like this
Firefox has none of that: implementing the firefox devtools protocol means reverse engineering it, and then sometimes it still breaks when Firefox updates!
Un1corn 5 days ago [-]
I haven't used the devtools protocol of Firefox but CDP is one of the worst protocols I had to work with. Everything is "experimental", inconsistencies between different domains, multiple ways to do some stuff and revealing internal stuff.
kg 4 days ago [-]
Seconding this, I've used CDP directly to solve problems and it's a horrible protocol with a really buggy implementation. The documentation is pretty sparse and the implementation is inconsistent with the documentation sometimes.
It's true that if you want to know what a method is named and which parameters it takes you can find that out, but I rarely found the answers I actually needed to use things correctly.
keepamovin 4 days ago [-]
I actually know CDP really well as I've used it extensively for a commercial product and found it to be the exact opposite. Admittedly there are undocumented things, and a learning curve, but it's been remarkably stable over the 7 years I've been deep into it.
Is there something I can help you folks with? I'm happy to provide guidance on how to do a certain thing in CDP, or help you debug issues you might have encountered with it.
Anyhow if you don't want to reply here, anyone with CDP questions or need feel free to reach out cris@dosaygo.com I can definitely help.
walls 4 days ago [-]
Yep, in certain cases requests/responses will only show up in the Fetch domain, sometimes only in the Network domain, and sometimes neither!
cxr 5 days ago [-]
A recent attempt to bring up an element in Firefox's inspector by right-clicking the element and selecting the appropriate menu item resulted in the fans on my machine spinning up and the process needing to be killed after it appeared to hang and started chewing through RAM. All in response to my attempt to get a relatively simple view of the DOM tree on the screen to interact with.
When I tried it again I observed an increase of 130MB RAM to bring up the initial window/view, along with noticeable lag to put its contents on screen and make the controls interactive. When I collapsed all the nodes so that the only nodes in the tree toggled open were the HTML body element and its ancestors, it ended up consuming 400MB more—to collapse tree nodes and show fewer things on the screen.
That's half a gigabyte to bring up a less usable tool than the original DOM Inspector that Joe Hewitt checked in to the mozilla.org CVS server back in 2001.
The fact that Firefox's devtools team has ignored the readily available information and guidance from Firefox's own repo about how to do large JS codebases because they instead favor doing a wholesale import all of the bad practices from the NodeJS/NPM world is a serious problem unto itself.
googlywoogly 5 days ago [-]
Chrome's/Google's attack on adblockers is why 'the ecosystem' now shifting away from chrome to firefox
surajrmal 5 days ago [-]
Except it's not. HN users aren't representative and all trackers show no discernable uplift of Firefox usage since manifest v3. There also exists chromium based browsers with continued v2 support.
yjftsjthsd-h 5 days ago [-]
> and all trackers show no discernable uplift of Firefox usage since manifest v3.
The browser that goes out of its way to protect user privacy against trackers doesn't show up in trackers. This is neither surprising nor particularly damning.
giorgioz 5 days ago [-]
Can anyone tell me some use cases for CDP commands?
In which situation is preferable to use CDP commands over Puppeteer?
gwittel 5 days ago [-]
Tools like Playwright and Puppeteer are abstractions on top of CDP. The other use case is when these frameworks don’t expose or don’t use a CDP command you need (often they hide some parameters for cross browser compatibility).
Webdriver BiDi is a future cross browser replacement:
Bidi’s not a viable replacement for some use-cases e.g. setting headers for just the main origin as it’s add header command adds the header to all requests potentially causing CORS issues
youngtaff 4 days ago [-]
Some things you can only do via CDP — last time I looked adding a HTTP header to requests that match a certain URL was only possible via CDP
bsimpson 4 days ago [-]
I believe CDP is how Decky Loader (the homebrew sidebar for SteamOS works). It attaches to the web app that draws SteamOS's UI and injects its own plugins to the sidebar.
aPoCoMiLogin 5 days ago [-]
very nice. there are things that won't show up in the network panel and you had to resort to proxy for debugging, especially when you are using puppeteer/etc for testing.
So many people building AI browsers definitely had this as an internal tool already lol, nice to see Chrome leaning in here; CDP is a huge pain to write and debug
ghxst 5 days ago [-]
I think they released this in 2023 somewhere, it's been hidden behind an experiment in the devtools settings.
foofoo12 5 days ago [-]
Very useful. Does anything similar exists for Firefox?
bryanrasmussen 5 days ago [-]
I would look at the Browser Console if I were trying to do something similar
in fact this is similar to a thing I wanted to do recently that I was calling JIT automation (using FF's browser console) but when I wanted to write an article about it they weren't too interested because FF specific.
DevTools -> Settings (cog, top right) -> Experiments -> Search for "Protocol Monitor" -> Check the checkbox
- Full documentation
- A stable API
- Tooling like this
Firefox has none of that: implementing the firefox devtools protocol means reverse engineering it, and then sometimes it still breaks when Firefox updates!
It's true that if you want to know what a method is named and which parameters it takes you can find that out, but I rarely found the answers I actually needed to use things correctly.
Is there something I can help you folks with? I'm happy to provide guidance on how to do a certain thing in CDP, or help you debug issues you might have encountered with it.
Anyhow if you don't want to reply here, anyone with CDP questions or need feel free to reach out cris@dosaygo.com I can definitely help.
When I tried it again I observed an increase of 130MB RAM to bring up the initial window/view, along with noticeable lag to put its contents on screen and make the controls interactive. When I collapsed all the nodes so that the only nodes in the tree toggled open were the HTML body element and its ancestors, it ended up consuming 400MB more—to collapse tree nodes and show fewer things on the screen.
That's half a gigabyte to bring up a less usable tool than the original DOM Inspector that Joe Hewitt checked in to the mozilla.org CVS server back in 2001.
The fact that Firefox's devtools team has ignored the readily available information and guidance from Firefox's own repo about how to do large JS codebases because they instead favor doing a wholesale import all of the bad practices from the NodeJS/NPM world is a serious problem unto itself.
The browser that goes out of its way to protect user privacy against trackers doesn't show up in trackers. This is neither surprising nor particularly damning.
In which situation is preferable to use CDP commands over Puppeteer?
Webdriver BiDi is a future cross browser replacement:
https://www.w3.org/TR/webdriver-bidi/
https://firefox-source-docs.mozilla.org/devtools-user/browse...
in fact this is similar to a thing I wanted to do recently that I was calling JIT automation (using FF's browser console) but when I wanted to write an article about it they weren't too interested because FF specific.