Faster Smarter JavaScript Debugging in Firefox DevTools(hacks.mozilla.org)
hacks.mozilla.org
Faster Smarter JavaScript Debugging in Firefox DevTools
https://hacks.mozilla.org/2019/05/faster-smarter-javascript-debugging-in-firefox/
73 comments
That is cool but I am wonder why no browser provided any HTTP request/response interception response. In 2020 we still rely on proxies which is crazy given the amount of heavily lifting browsers do these days.
It'd probably be possible to build this using service-workers or an extension.
I really wish Mozilla would add a way to disable CORS for local development.
The best FF dev tool feature is definitely vim mode.
Inline breakpoints and human-friendly variable names are gamechangers! Looks like FF is going above and beyond Chrome devtools with this update.
Can it inspect WebSockets frames yet? I'm a Firefox user but I miss that sometimes when developing stuff.
I heard that this was going to be a GSOC project this summer, but I'm not sure if that was approved or not.
Mozilla methodology: staffs should avoid well defined works so that volunteers, interns, and students can do them.
It’s not a bad strategy: just figuring out what to do can be much harder than getting it done (which can be more easily delegated). Architects (of old) made the big bucks in the days; now according to the google model they’ve all become senior engineers and the definition of and piecing off of work is much less formal (not to mention that it might go out to interns or the community rather the junior devs).
I can also picture it organically happening: if I were a core dev, would I focus on the issues "anyone" could pick up, or the ones that only someone as deeply invested into the code base as me would have any hope of untangling?
Firefox is not their primary product and they have no competition. /S
Oh... I consider Mozilla methodology a good methodology. Staffs probably can do both well and ill defined works better than volunteers, but they do have comparative advantage in ill defined works. A problem with methodology is that well defined works can be delayed, but Mozilla do have massive contributor pool so that it is not usually a problem.
It was, here's the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=885508
This is the big one that sends me back to Chrome every time I start to get settled in Firefox.
Looks like they finally added resizable columns in the networks tab! https://bugzilla.mozilla.org/show_bug.cgi?id=1358414
As much as I like a Firefox, no inline/live editing of Javascript leaves things a bit frustratingly behind the curve. Even Edge Classic has that, and it's terrible.
Those have worked for a while now? Like https://umaar.com/dev-tips/129-inline-breakpoints/
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 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.
We (Chrome DevTools) have had inline breakpoints since at least January 2017: https://umaar.com/dev-tips/129-inline-breakpoints/
The human-friendly variable mapping is very interesting, though. We'd love feedback on how well it works out in the wild.
The human-friendly variable mapping is very interesting, though. We'd love feedback on how well it works out in the wild.
Happy to discuss collaborating on mapping variables. The current approach is based on re-parsing with babel, but we would like to extend source maps to include relevant mapping data.
https://twitter.com/auchenberg/status/1129435519727820800
https://twitter.com/auchenberg/status/1129435519727820800
I'm really liking this recent uptick in Google/Mozilla/Opera development/rivalry lately. It's good for consumers. If only things happened more quickly...
Really? I generally see the opposite these days with everything moving to chromium (Opera, Chrome, Safari, and even Edge now all use it). Its kind of like a creepy consolidation.
I would say though Firefox does remain a strong (if the last) holdout.
I would say though Firefox does remain a strong (if the last) holdout.
FF and Safari are both shipping some great stuff that we don't have in Chrome DevTools.
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...
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...
That's got nothing to do with Chromium becoming ubiquitous as far as market share goes. Which is bad for everyone.
Sorry, given that this is a thread about DevTools I thought the conversation was scoped to DevTools. Didn't realize we were talking about browser share at large.
Also:
> everything moving to Chromium... [including] Safari
This is the opposite of true
> everything moving to Chromium... [including] Safari
This is the opposite of true
When will safari provide a VM image so developers can actually test things on it?
Why would you need to? Just test things on another WebKit browser, it will work just as well on Safari.
What actively-developed WebKit browsers still exist for Windows?
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.
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.
Firefox dev edition has been my go to lately, highly recommended if you do a lot of markup / css debugging. Being able to see outlines around elements as I hover / scan through the DOM easily doubles my speed.
I have found the CSS "changes" tab to be very useful. Just tweak the CSS and once you're satisfied you can just view a diff and use that to modify your code base [0]
[0]: https://developer.mozilla.org/en-US/docs/Tools/Page_Inspecto...
[0]: https://developer.mozilla.org/en-US/docs/Tools/Page_Inspecto...
I like FF's diff format. For anyone who hasn't seen it, they give you the old code, followed by the new code:
/* I think they also include URL info up here */
h1 {
/* background-color: blue; */
background-color: grey;
}
I agree. Whenever I have something strange going on with CSS Grid or Flexbox layouts, the issue is usually easier to find with Firefox than Chrome.
Let's see how the new JS debugger feels.
Let's see how the new JS debugger feels.
Grid Inspector: https://developer.mozilla.org/en-US/docs/Tools/Page_Inspecto...
Flexbox Inspector: https://developer.mozilla.org/en-US/docs/Tools/Page_Inspecto...
Flexbox Inspector: https://developer.mozilla.org/en-US/docs/Tools/Page_Inspecto...
Can you not do that with every browser's dev tools?
Correct me if I'm wrong, but web-socket debugging in FF isn't supported?
I ran into this last night, Chrome shows me what requests are going over websockets, FF does not.
I ran into this last night, Chrome shows me what requests are going over websockets, FF does not.
I have always found Fiddler to be far more useful when debugging web traffic. It runs independently of applications, tabs, etc and allows for easy re-invocation of requests. And you can also test error handling easily by overriding the request and sending back an invalid response.
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.
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.
They're working on this as part of (ironically) Google Summer of Code. Here's the bug: https://bugzilla.mozilla.org/show_bug.cgi?id=885508
(Yeah, it's overdue.)
(Yeah, it's overdue.)
You know, I've been using Firefox Dev Edition since it was Firefox Aurora (or Beta, I guess?), and it's great to hear that they are improving the dev tools! But I have to ask this in the nicest way possible: does anyone else think the tools just don't work a lot of the time?
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?
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?
The first three bugs you listed are related to source maps. I haven’t used Firefox in a long time but I have experienced the same behavior in Chrome and VS Code when debugging TypeScript. It turns out, there was a bug in the loader that was generating source maps. Perhaps your issue is tooling and not the browser?
I much prefer Firefox dev tools over chrome. The only time I use chrome is web socket stuff. Debugging css grids in Firefox (which I learned this year) is amazing.
fyi, we are picking up the websocket work this summer; so first parts might show up in 69, latest 70.
That's wonderful to hear! Websockets have definitely been a pain point for me trying to use FF dev tools in the past.
Chrome also has CSS media rendering debug capabilities. I couldn't find these on FF.
Article author here: You are describing a lot of issues that should be fixed. If you could try out 68 for a bit, you can help us confirm.
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.
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.
I actually have the opposite problem. For some reason, debugging JS with IntelliJ (where I'm most productive) doesn't work nicely on FF so I have to keep a Chrome tab open, and it's just unusable since it's determined to open a tab on Webpack's bundled file which is enormous and lags for like 10 seconds on each page reload. FF is most wonderful in comparison when I have to debug in the browser.
IntelliJ uses different adapters for Firefox and Chrome, so they might have side effects. We also touched a lot of our protocol APIs when adding column breakpoints, so I will reach out to see if we can improve.
Yup, I also tried to use the debugging tools in the new FF Dev Edition with a larger React codebase and it's a bit buggy for sure.
Was this with 68? If so, could you share specific around what felt buggy.
I've experienced the same. Sometimes inexplicable things occur in the debugger and I have to switch to Chrome.
The superior layout of the tools + handy way to quickly locate events keep me coming back.
Hopefully, the tools improve in v67.
The superior layout of the tools + handy way to quickly locate events keep me coming back.
Hopefully, the tools improve in v67.
> superior layout of the tools
Which bits?
> 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)
Which bits?
> 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)
Note the 3 pane layout vs Chrome's 2 pane. I can see more at a glance and more effective use of the monitor - plus I can see the Box Model (or Flex model) without having to scroll down. https://i.imgur.com/Ts3Ygk5.png
And yes, referring to the event bubble next to the element.
And yes, referring to the event bubble next to the element.
Bug reports are welcome, it may very well be something about your setup that hasn't been reported yet: https://bugzilla.mozilla.org/enter_bug.cgi?product=DevTools&...
(I'm a Mozilla dev but not involved with Devtools, though I know a few folks, happy to provide pointers if you need 'em)
(I'm a Mozilla dev but not involved with Devtools, though I know a few folks, happy to provide pointers if you need 'em)
They are handling bugs through Github issues too, everything is under DevTools org (https://github.com/firefox-devtools)
Article author here. We are monitoring both, but are recently managing all our work in bugzilla.
Your comments echo my sentiments exactly, but I do think this update is mainly about resolving these points. They've done a lot of work in recent years on a revamp of the foundations of the DevTools, and I think they're starting to pay off now.
FF has had more solid console and debugging tools now for almost two years and it's one of the main reasons I switched completely from Chrome. It really is a superior, more reliable experience. And the console is light years beyond chrome. I definitely recommend it.
What makes you say that FF Console is lightyears beyond Chrome? (I write the Chrome DevTools docs)
Mainly the request/response logging. It's all in one place. I can click an xhr and it pops up right in the same window in a tabbed interface. I can see the request, response, headers, pretty json output if any. In chrome I click on an xhr, it takes me to a different tab where I have to scroll and find that request manually. I then have to switch back and forth manually if I need to go to other xhrs. Maybe this has changed in the last year? I don't know but that alone merited the switch.
Does hiting F2 in Firefox freeze the browser side of things (mouse position, mouse click state, css animations state, select dropdown openness state), basically everything? Or are there other tools for that? I have more problems with "debugging" CSS than javascript
A few years ago, while working at an agency, I was using the Firefox Developer Edition to build the front-end for a website. I was presented with a very weird UI bug from the client that I could not reproduce whatsoever. It was driving me mad.
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.
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.
To be fair, when figuring out bugs like that, if it doesn't appear in your dev environment, you'd definitely start by replicating the client's environment as closely as possible, especially their browser version (and possibly their OS for obscure stuff).
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.
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.
Trying to reproduce across browsers is good policy too, IMO
Agree with both points. My perspective at the time, although I was doing cross browser testing, was frustration from my expectations of the expected rendering behaviour between two browsers that I thought were the same, besides the addition of some new dev features.
Af far as understand Canarys eqvivalent is Firefox Nightly. Firefox Development Edition is not beta it is just different flavour of FF.
Firefox Developer Edition is actually based on Firefox Beta, which is an intermediate release between regular Firefox and Nightly. Your equivalence still stands, however.
Great. Last time I tried Firefox dev edition a few months ago I had huge memory leaks, upwards of 2GB with a single tab after a few hours of use. It seems much better with the latest version.
https://developer.mozilla.org/en-US/docs/Tools/Debugger/Set_...
Will certainly be something I use now and again