
Faster Smarter JavaScript Debugging in Firefox DevTools - edmorley
https://hacks.mozilla.org/2019/05/faster-smarter-javascript-debugging-in-firefox/
======
dlbucci
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?

~~~
philliphaydon
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.

~~~
digitarald
fyi, we are picking up the websocket work this summer; so first parts might
show up in 69, latest 70.

~~~
vanilla_nut
That's wonderful to hear! Websockets have definitely been a pain point for me
trying to use FF dev tools in the past.

------
mouzogu
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.

~~~
omnimus
Af far as understand Canarys eqvivalent is Firefox Nightly. Firefox
Development Edition is not beta it is just different flavour of FF.

~~~
sciurus
Firefox dev edition is based on the beta channel.

(Disclosure: I work for Mozilla)

~~~
mouzogu
Thanks for clarification. I was not aware at the time, perhaps my oversight or
it may have not been clear on the website - was a couple years ago so I can't
recall.

------
matthewvincent
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.

~~~
sebazzz
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...](https://developer.mozilla.org/en-
US/docs/Tools/Page_Inspector/How_to/Examine_and_edit_CSS#Track_changes)

~~~
kaycebasques
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;
        }
    

We (Chrome DevTools) have a Changes tab but no nice diff export like FF.
[https://developers.google.com/web/updates/2018/01/devtools#c...](https://developers.google.com/web/updates/2018/01/devtools#changes)

------
hahawhat222
Inline breakpoints and human-friendly variable names are gamechangers! Looks
like FF is going above and beyond Chrome devtools with this update.

~~~
haolez
Can it inspect WebSockets frames yet? I'm a Firefox user but I miss that
sometimes when developing stuff.

~~~
dblohm7
I heard that this was going to be a GSOC project this summer, but I'm not sure
if that was approved or not.

~~~
sanxiyn
Mozilla methodology: staffs should avoid well defined works so that
volunteers, interns, and students can do them.

~~~
seanmcdirmid
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).

~~~
vanderZwan
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?

------
waingake
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.

~~~
sebazzz
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.

------
grimgrin
Logpoints are v cool I think

[https://developer.mozilla.org/en-
US/docs/Tools/Debugger/Set_...](https://developer.mozilla.org/en-
US/docs/Tools/Debugger/Set_a_logpoint)

Will certainly be something I use now and again

~~~
SahAssar
That's sorta possible already, just use a conditional breakpoint and end it
with `return false;` and it will act the same.

------
mnm1
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.

~~~
kaycebasques
What makes you say that FF Console is lightyears beyond Chrome? (I write the
Chrome DevTools docs)

~~~
mnm1
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.

------
afturner
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...

~~~
0xDEEPFAC
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.

~~~
kaycebasques
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/](https://webkit.org/blog/8452/canvas-debugging/)

Flexbox inspector: [https://developer.mozilla.org/en-
US/docs/Tools/Page_Inspecto...](https://developer.mozilla.org/en-
US/docs/Tools/Page_Inspector/How_to/Examine_Flexbox_layouts)

Fonts tab: [https://developer.mozilla.org/en-
US/docs/Tools/Page_Inspecto...](https://developer.mozilla.org/en-
US/docs/Tools/Page_Inspector/How_to/Edit_fonts)

~~~
zachwood
That's got nothing to do with Chromium becoming ubiquitous as far as market
share goes. Which is bad for everyone.

~~~
kaycebasques
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.

------
rehemiau
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

------
_pdp_
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.

~~~
SahAssar
It'd probably be possible to build this using service-workers or an extension.

------
bgorman
I really wish Mozilla would add a way to disable CORS for local development.

------
bleuarff
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.

------
hajile
The best FF dev tool feature is definitely vim mode.

