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?
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.
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.
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.
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.
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.
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.
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.
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.
Firefox Developer Edition is actually based on Firefox Beta, which is an intermediate release between regular Firefox and Nightly. Your equivalence still stands, however.
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.
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]
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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
Safari uses Chromium, how so? I thought they were based on the same engine then they split but that was like 6 years ago. I couldn't find anything on it with a simple search.
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
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.
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.
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?