> Also means if it works in Firefox it will most likely work in chrome.

Can’t relate at all. In my limited frontend experience, I’ve run into a lot of rendering deferences between WebKit and Blink, and even more between Gecko and Blink. Sometimes the differences are subtle yet break pixel perfection; sometimes the whole layout is broken.

No op, but for me I use Chrome's "Replay XHR" constantly. Literally 100s of times/day. So I appreciate that it's simple as right-click->open menu->left-click "Replay XHR". AND that it takes me right back to where I was before: namely either the "Response" "tab" (not sure what to call that menu tab/option) or "Preview" "tab". AND that the "Preview" "tab" automatically detects and renders the JSON returned from my server.

FF requires several clicks to re-run XHR. And doesn't return me to where I was before. And doesn't render my JSON.

Thanks for listening.

not op - 1 click clear storage/site data button.

Do any of the firefox devs use chrome dev tools to see what's missing in FF/nice to have?

"Blocking" is not the right verb, but this is representative of a whole category of bugs in dev-tools that makes using FF for dev work very frustrating: https://bugzilla.mozilla.org/show_bug.cgi?id=1553836 ( Cmd/Ctrl+A selects the entire panel content so it's hard to copy just a response payload for example), open for 7 months

I was tracking some similar ones related to displaying JSON in the Network pane that were open for years.

In my specific case, Chrome also displays EventSource events just like it does with Websocket frames, but Firefox treats that as a normal XHR, waiting until the very end to display the content. That is a little closer to "blocking" but also very niche, I guess