It's something I noticed especially when they switched to React. A few examples I frequently experience:
1) Stepping through TS frequently switches back to the source JS.
2) Breakpoints don't always go away, and sometimes a page reloads with an invisible breakpoint, that stops the code, but doesn't show up in the list of breakpoints, and doesn't seem to be removable.
3) Breakpoints don't always stop at the the right place.
4) After having the tools open for a while, the tab starts freezing for multiple seconds every few seconds (GC, according to the perf tab, so it's either my code or the dev tools)
This comes from a place of love, and I'll still always use FF over Chrome, but I really have to ask if anyone else experiences the same issues, or if it's perhaps my setup/code that causes the problems?
(I'm a Mozilla dev but not involved with Devtools, though I know a few folks, happy to provide pointers if you need 'em)
The superior layout of the tools + handy way to quickly locate events keep me coming back.
Hopefully, the tools improve in v67.
> handy way to quickly locate events
Are you referring to how FF shows `event` next to DOM nodes?
(I am reconnoitering for Chrome DevTools so don’t answer if you view us as the storm troopers)
And yes, referring to the event bubble next to the element.
I will aim for another post going into more of the issues and how we fixed them and sharing some more frustrating breakage developers might have experienced and how we improved it.
After an hour or so of frustration I realised that the bug did not occur on Chrome or Firefox "Standard" Editions and was only occuring on Firefox Developer Edition.
Now I know its not fair to make a judgement based on a single bug, too many variables at play etc but the lesson I learnt as a stressed out, time-pressured developer is not to ever ever ever use a browser that wasn't the standard version of a browser for development, the one most likely to be used by the client or end-user.
I can't recall exactly but I'm pretty sure I had a similar experience with Chrome Canary vs regular Chrome too. Although I think Canary is presented as a somewhat unreliable beta-ish version of Chrome whereas I had believed that FF Dev edition would have the same rendering engine as the equivalent FF standard, so long as they where the same version number.
In any case If I had some feedback for the team working on FF dev tools it would be to implement expand to unminifed line number on minified css and js. When I inspect an element and want to jump to a particular rule in the CSS it always expands to the first line of the file only and not whatever line that rule would be on in the uminified version of the file. Chrome does this and I find it so useful it prevents me from using FF.
It's safe (and wise) to develop in Dev editions of browsers, so long as you're ready to debug in mainstream editions when the time comes.
(Disclosure: I work for Mozilla)
/* I think they also include URL info up here */
/* background-color: blue; */
Let's see how the new JS debugger feels.
Flexbox Inspector: https://developer.mozilla.org/en-US/docs/Tools/Page_Inspecto...
The bigger issue is when local variables aren't captured by the context when paused in chrome. I'm curious how the Firefox devtools handle that.
The human-friendly variable mapping is very interesting, though. We'd love feedback on how well it works out in the wild.
I ran into this last night, Chrome shows me what requests are going over websockets, FF does not.
Fiddler is not the most user-friendly (it appears to be a bit thrown together), but it is very useful if you know how to find the right knobs.
(Yeah, it's overdue.)
Will certainly be something I use now and again
I would say though Firefox does remain a strong (if the last) holdout.
Canvas debugger: https://webkit.org/blog/8452/canvas-debugging/
Flexbox inspector: https://developer.mozilla.org/en-US/docs/Tools/Page_Inspecto...
Fonts tab: https://developer.mozilla.org/en-US/docs/Tools/Page_Inspecto...
> everything moving to Chromium... [including] Safari
This is the opposite of true
FWIW, the assumption that safari and some random WebKit browser will behave the same seems unsafe to me. The release version of safari will probably be on a newer/older WebKit edition and stuff like tracking protection might behave differently.