Sad to see a post by Mozilla only referencing Mac and Windows shortcuts to start the debugger. Most of the web developers I know are using Linux for web development, including javascript (some are using MacOS, none Windows).
On Ubuntu, the debugger is started by using <CTRL><SHIFT>S (like Windows actually).
Unless the Desktop Environment interferes with Firefox shortcuts. I've ran into oddities where a DE has hijacked a shortcut from happening, but I can't off the top of my head think of a specific case, I just remember it happening. Not on standard Ubuntu with Firefox though.
Hardly any. I've been interchangeably using the two OS' for a couple years now, and the only difference in Firefox shortcuts (general, not just dev tools) I've noticed is the one for jumping to the nth tab: It's Ctrl+<number> under Windows and Alt+<number> under Linux (at least Ubuntu with Unity or Gnome).
If we’re doing anecdata, then every web developer I know is on Macs, apart from those at the company I’m consulting for at the moment who have mostly standardised on Windows.
If someone says that Linux should be included and mentions he knows a lot of web developers using Linux, then his added comment is relevant. Windows instructions were already included so your reply wasn't needed and I assume you didn't understand the Linux reply.
Depends on where you work. I work at a primarily Linux shop. I'm one of 3 people using Windows, compared to everyone else which are using Ubuntu and only one person is using Mac. Although in any regard, I find usually unless the Desktop Environment on Linux interferes most "Windows" commands work with Firefox on Linux. Oh and I'm usually dual-booting, so I'm either on Ubuntu or Windows whenever I'm doing web development.
Linux isn't just a distribution platform, it's also sensibly a development platform. I rather work on the system I'm building for if and when possible.
Edit:
I use .NET Core and while I have done it from Windows most of my time in the past few months, I also do code in .NET Core from Mac and Ubuntu (more Ubuntu than Mac). It works good enough so long as you use Visual Studio Code for debugging.
Personally, I don't imagine working under any other OS than Linux as a web developer. And hey, Java and .NET Core/Mono is quite pleasant to work with under non-Windows operating system.
Will confess that most of it is scientific applications for the science and modeling team, which runs a mix, leaning towards Mac and Linux for... reasons, so dev work on Linux is better suited.
The "Business" side of the house uses C# and IIS on Windows.
At companies that let you decide for yourself (I've worked at 4), it's Mac and Linux. Windows is rare.. but there's usually one or two. Different IDEs. Just use whatever your more comfortable/efficient with.
Admin use Windows, Mac is rare.
I find it strange, in this day and age, being forced to use a single OS because "policy", especially when developing for an "open platform".
> Sad to see a post by Mozilla only referencing Mac and Windows shortcuts to start the debugger. Most of the web developers I know are using Linux ...
Maybe because the shortcuts will be (slightly) different across the various Linux desktops (desktop environments and Linux distributions). There is not one Linux desktop like there's one macOS or one Windows.
I tried to use the Firefox debugger recently, but I could find where you set "event listener breakpoints" (e.g. a breakpoint that stops whenever a click handler runs, regardless of which element was clicked). Some documents seemed to suggest that Firefox has this feature but I tried multiple versions of Firefox (including fiddling with the "new debugger frontend" flag in about:config) but I just couldn't find it anywhere?
Set about:config?filter=devtools.debugger.new-debugger-frontend to false, then reopen the debugger and expand the right pane, the Events tab should be there: https://i.imgur.com/GLGrc7y.png.
Here's something which is still missing from both Firefox and Chrome debuggers: "tracing" breakpoints.
That's one of the few nice/advanced features from Xcode and Safari, aside from making a breakpoint conditional you can:
* skip it the first n times (default: 0)
* make it non-breaking
* associate various actions which are executed if the breakpoint "triggers" (the condition matches) even if the breakpoint is non-breaking, in Safari these actions are "Log Message" (formatted plain text), "Evaluate" (arbitrary javascript code), "Play Sound" (beep on every tripping of the breakpoint) and "Probe Expression"[0]: https://webkit.org/blog/5435/breakpoint-options/
[0] a special kind of table logging which integrates with the debugger rather than the (separate) console tab
You can at least both "Log Message" and "Evaluate" in Chrome with conditional break points. Calling console.log is falsy, so calling it from conditional break points just causes it to log the message (you also have access to any variables in scope of the breakpoint that you can use to build the message). You can do the same thing with executing random JavaScript. Just put the statement and add && false to make sure it always returns false.
Technically sure, but that makes it less discoverable as developers tend to look for breakpoints rather than tracepoints.
So UX/discovery-wise adding these features as advanced extensions of breakpoints is more sensible than breakpoints being a special case of tracepoints.
Conditional breakpoints have been around for years, which solve all of those via arbitrary javascript. You just make the condition falsey if you don't want it to break (or `doAnything() && false`). Skip-counters are just a global counter and `x++ > N`. "Probe Expression" does look pretty neat though, that'd be a bit of a pain to do by hand (probably just viewing logs, which does provide rich objects in recent-ish years).
Granted, the UI isn't as clear about the capabilities, but I generally prefer "run JS, return true" over "choose one of N kinds of things to do", even if one of the N is "run JS, return true". Minus skip counters, those are a bit annoying by hand (needing globally unique var names and all).
I'm not sure when Firefox's built-in debugger got it, but I see search results implying they've been part of FireBug since 2007 at the very least. And I don't remember Chrome's debugger ever not having it (once they got their current-gen-like one, iirc it launched with extremely limited devtools?), though I could easily be forgetting the early days.
DevEdition is our fourth release channel, along with Stable, Beta, and Nightly builds. The engine is generally based on Beta, but we can ship features to DevEdition separately from mainline Firefox. For example, we can ship new developer tools to that channel before they land in Beta, it runs in its own separate profile by default, we allow Developer Edition to disable the add-on signing requirement, etc.
Apart from giving you access to all these features, being based on the beta also means that you can discover potential breakage in new Firefox versions before those hit the general public.
Pardon me if this is a silly question, but in the about:config page of Firefox Developer Edition the value for app.update.channel is aurora. But AFAIK, the aurora channel was stopped since April 18th of this month.
The aurora tree/part of the release cycle has gone away, but dev edition needs a separate update channel from beta, and was already using "aurora", so it was obviously less work to keep the name around just for the channel rather than rename it (and that might have prevented keeping existing dev edition users getting updates)
(So the _channel_ didn't actually ever go away, it just changed which tree it drew from)
(Tree being synonymous with "code repository" throughout this comment)
Aurora used to be a separate pre-beta, post-nightly release channel:
Release <--- Beta <--- Aurora <--- Nightly
In 2014, we rebranded Aurora builds to "Developer Edition" to give it better visibility and ship experimental features that we thought would be interesting to web and add-on developers.
Earlier this year, we sped up our time-to-release by removing Aurora from the pipeline, but we kept it as a separate channel roughly at parity with Beta:
Thanks for the reply sir. I have one more question. I was very excited to use quantum, so ended up using developer edition. I am using it on my macOS High Sierra.
The battery usage and Energy impact that I observed from Activity Monitor application in macOS was very surprising.
Both parameters were quite high and the battery was draining very quickly. I don't have the screenshot. I tried searching for a solution like tinkering the about:config fields etc. but couldn't find any.
The developer edition is bit more bleeding edge than beta, but less than nightly. Nightly is updated daily. I'm not sure what the developer frequency is. But if your sporting it, you're getting the fresh features not entirely ready.
Isn't this incorrect? The developer edition appears to be built from the beta version. You get some alternate switches turned on, such as extensions no longer required to be signed & other stuff, but none of it is specifically new.
If you're a developer, use the developer edition, it's amazing. I'm too lazy to give you a feature-by-feature breakdown of what hasn't hit stable yet but... up until just recently "quantum" was one of them.
The news about FF getting faster is just hitting the mainstream now but developer edition has had it for months, and I haven't suffered any noticeable bleeding edge issues (mostly because I'm not on nightly). This might have to do with my update cadence with arch (firefox-developer is in the AUR) but I think more likely it's the distance from nightly.
Anecdotally I find it to be just the blind amount of "bleeding edge" (others described it well, behind nightly but ahead of stable), and I am now lost whenever I try to debug anything in chrome.
Since version 57 I have a strange behavior in the debugger (debian 9) : there is a line difference between where I click and the line selected. For a breakpoint I have to click the line above, idem for getting var values.
Fully agree with you. The old dark theme feels more comfortable (less contrast between colors). Each and every time I open the devtools now this thought crosses my mind.
It's similar if you look skin deep. Differences emerge once you start using it on daily basis.
The coolest thing FF has over Chrome is the little [ev] icon next to an element that shows what events are connected to it. Saves me lots of time trying to track things down.
The coolest thing Chrome has over FF is that stepping through code is so much faster. There is no lag at all, while there is one in FF. It also has a "Search All" mode where it will look through all your code (html, js, css) to find a string.
This is also a big barrier for me using firefox in development, and pre-v57 Firefox used to have an extension for websockets that was nice, but its gone now with the new web extension APIs.
I have a similar thing but with profiling JS performance: if you profile a page in Chrome and then inspect the source code, it gives estimates of seconds spent per line of code. Firefox does not have this.
Being able to detect which function is the bottleneck is great, but being able to then figure out where the time is spent inside that function can be very enlightening too.
Firefox Debugger is amazing, but I have some problems with performance. If I enable DevTools, then entire browser (other tabs too) hanging for 1-2 minutes while page with DevTools is reloading. I think it may be because a lot async calls were performing, about couple hundreds (we use RequireJS and every sourcefile loaded through different request).
69 comments
[ 2.6 ms ] story [ 23.0 ms ] threadOn Ubuntu, the debugger is started by using <CTRL><SHIFT>S (like Windows actually).
Linux is only used for Java based backends, when deploying into production.
With .NET deployments being done on IIS, even with .NET Core.
Some of the designers are using Photoshop on macOS.
Anecdote data.
Linux isn't just a distribution platform, it's also sensibly a development platform. I rather work on the system I'm building for if and when possible.
Edit:
I use .NET Core and while I have done it from Windows most of my time in the past few months, I also do code in .NET Core from Mac and Ubuntu (more Ubuntu than Mac). It works good enough so long as you use Visual Studio Code for debugging.
Will confess that most of it is scientific applications for the science and modeling team, which runs a mix, leaning towards Mac and Linux for... reasons, so dev work on Linux is better suited.
The "Business" side of the house uses C# and IIS on Windows.
Admin use Windows, Mac is rare.
I find it strange, in this day and age, being forced to use a single OS because "policy", especially when developing for an "open platform".
Maybe because the shortcuts will be (slightly) different across the various Linux desktops (desktop environments and Linux distributions). There is not one Linux desktop like there's one macOS or one Windows.
That's one of the few nice/advanced features from Xcode and Safari, aside from making a breakpoint conditional you can:
* skip it the first n times (default: 0)
* make it non-breaking
* associate various actions which are executed if the breakpoint "triggers" (the condition matches) even if the breakpoint is non-breaking, in Safari these actions are "Log Message" (formatted plain text), "Evaluate" (arbitrary javascript code), "Play Sound" (beep on every tripping of the breakpoint) and "Probe Expression"[0]: https://webkit.org/blog/5435/breakpoint-options/
[0] a special kind of table logging which integrates with the debugger rather than the (separate) console tab
You can obviously do that in any browser, it's just inflexible, ugly, error-prone and inconvenient.
So UX/discovery-wise adding these features as advanced extensions of breakpoints is more sensible than breakpoints being a special case of tracepoints.
Granted, the UI isn't as clear about the capabilities, but I generally prefer "run JS, return true" over "choose one of N kinds of things to do", even if one of the N is "run JS, return true". Minus skip counters, those are a bit annoying by hand (needing globally unique var names and all).
I'm not sure when Firefox's built-in debugger got it, but I see search results implying they've been part of FireBug since 2007 at the very least. And I don't remember Chrome's debugger ever not having it (once they got their current-gen-like one, iirc it launched with extremely limited devtools?), though I could easily be forgetting the early days.
> Build, test, scale and more with the only browser built just for developers.
This is the only description I could find on their website. What's the difference to the normal version?
Still curious about what's special about the dev edition.
some preconfigured dev-friendly things ? like more verbose logging ...
a separate release channel between nightly and stable ?
Pardon me if this is a silly question, but in the about:config page of Firefox Developer Edition the value for app.update.channel is aurora. But AFAIK, the aurora channel was stopped since April 18th of this month.
This is the screenshot : https://imgur.com/r5Kcqb3
(So the _channel_ didn't actually ever go away, it just changed which tree it drew from)
(Tree being synonymous with "code repository" throughout this comment)
Earlier this year, we sped up our time-to-release by removing Aurora from the pipeline, but we kept it as a separate channel roughly at parity with Beta:
Which is where things are today.The battery usage and Energy impact that I observed from Activity Monitor application in macOS was very surprising.
Both parameters were quite high and the battery was draining very quickly. I don't have the screenshot. I tried searching for a solution like tinkering the about:config fields etc. but couldn't find any.
The news about FF getting faster is just hitting the mainstream now but developer edition has had it for months, and I haven't suffered any noticeable bleeding edge issues (mostly because I'm not on nightly). This might have to do with my update cadence with arch (firefox-developer is in the AUR) but I think more likely it's the distance from nightly.
Anecdotally I find it to be just the blind amount of "bleeding edge" (others described it well, behind nightly but ahead of stable), and I am now lost whenever I try to debug anything in chrome.
Example: https://support.cdn.mozilla.net/media/uploads/images/2016-09...
The coolest thing FF has over Chrome is the little [ev] icon next to an element that shows what events are connected to it. Saves me lots of time trying to track things down.
The coolest thing Chrome has over FF is that stepping through code is so much faster. There is no lag at all, while there is one in FF. It also has a "Search All" mode where it will look through all your code (html, js, css) to find a string.
This feature is called "Search Sources" in Firefox. https://imgur.com/U515D8X
https://i.imgur.com/BFejDaf.png
Being able to detect which function is the bottleneck is great, but being able to then figure out where the time is spent inside that function can be very enlightening too.