Live data from Hacker News

Firefox Debugger

mozilladevelopers.github.io

31–40 of 70 posts

Re: Firefox Debugger

#31
Is there any way to restore older dark theme for Firefox developer tools? I mean more metallic looking. The new one is too black.

Re: Firefox Debugger

#32

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 S (like Windows actually).

There are only minor differences between the Windows and Linux shortcuts. See https://support.mozilla.org/en-US/kb/keyboard-shortcuts-perf... for a full list.

Re: Firefox Debugger

#33
post #31

Is there any way to restore older dark theme for Firefox developer tools? I mean more metallic looking. The new one is too black.

Click the cog icon, top-right for DevTools options. Available themes are Dark, Light, Firebug.

Re: Firefox Debugger

#34
post #31

Is there any way to restore older dark theme for Firefox developer tools? I mean more metallic looking. The new one is too black.

Click the cog icon, top-right for DevTools options. Available themes are Dark, Light, Firebug.

Compare this new dark to one that was there a few versions back. I'm talking about the older one.

Example: https://support.cdn.mozilla.net/media/uploads/images/2016-09...

Re: Firefox Debugger

#35
post #24

Slightly OT; What's the "Developer Edition"? > 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?

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.

Re: Firefox Debugger

#36

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-bre…

As a Lisper, tracing is something I also often miss on other platforms. It's really powerful, particularly when debugging "functionnal" code.

Re: Firefox Debugger

#37

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-bre…

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 i…

> You can at least both "Log Message" and "Evaluate" in Chrome with conditional break points.

You can obviously do that in any browser, it's just inflexible, ugly, error-prone and inconvenient.

Re: Firefox Debugger

#38
post #27

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-bre…

I get your point but a non-breaking breakpoint sounds like a contradiction. Maybe it should be called a tracepoint?

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.

Re: Firefox Debugger

#39
post #3

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 S (like Windows actually).

Are there any shortcuts on Linux which are different from those on Windows by default?

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+ under Windows and Alt+ under Linux (at least Ubuntu with Unity or Gnome).

Re: Firefox Debugger

#40

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-bre…

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 i…

In fact, the linked tutorial addresses how to do exactly that in Firefox: https://mozilladevelopers.github.io/playground/debugger/04-c...
Post reply on HN