A new set of Firefox Developer Tools features | Hacker News Reader

A new set of Firefox Developer Tools features

mzl.la

256 pointsxOnic40 comments

As usual, the event listeners shown are just jQuery making the binding. It would be really great if it actually stepped back through the stack to see what initially called jQuery's bind. I can't think of any general solution to the problem that covers all libraries, but jQuery is so ubiquitous it should be worthwhile.

That would be awesome! I filed a bug to ask how plausible it is: https://bugzilla.mozilla.org/show_bug.cgi?id=1048033

Perhaps they could make it ignore blackboxed scripts by emitting a fake event and waiting until a non-blackboxed call is made, then intercepting that call and showing that function as the actual listener? That idea falls apart of the blackboxed listener changes the state of the program, though.

Or maybe an extra argument to addEventListener that takes a reference to a function that is the "real" listener? Then libraries like jQuery would just pass the user-provided function along in their own code.

In Chrome Devtools debugger, you can click on the Async checkbox next to where the call stack is. So, when paused, you can see the full stack. (If you are not on the latest chrome, this might need to be enabled in experiments).

And this show why it is a bit difficult to choose what to show, among all the things from the call stack (including async stuff) that triggered something. For one thing you could possibly ignore libary code (e.g. http://www.divshot.com/blog/tips-and-tricks/ignoring-library... ) but if you have a medium to big SPA with many backbone/wreqr events, let's say, you would still need to look in the stack manually.

FWIW, be careful leaving this checkbox ticked when profiling code: it can consume 30%+ of CPU cycles, dwarfing everything else.

Thanks for the info!

So you want something more like this? http://i.imgur.com/MCKla78.png

We have it working and will be adding it very soon. It will also be very easy for library authors to add their own event parsers to our tools.

Ah, yes that's great!

I found that (in some browsers - not all) that calling `toString()` on the function that has been attached (which you can get by poking around in the jQuery cache) returns the raw, formatted, function - with comments, etc. You can then do a simple `indexOf()` on the `textContent` of the `<script>` tag (for loaded scripts I do an Ajax get to pull in the text of the script, which isn't perfect since remote domains fail, but its a start).

My Visual Event tool makes use of that:

  * https://sprymedia.co.uk/article/Visual+Event+2
  * https://github.com/DataTables/VisualEvent

The end result is that, when possible (Safari and Chrome) the script will tell you where the event listener was bound.

I haven't looked into it, but I presume the Firefox dev tools are using information directly from the DOM, since they have access to that. But there is no public interface in DOM to get the event listeners for a node, which I cursed at the time, but in retrospect it makes the above possible.

That's pretty cool stuff, I like being able to see at a glance which elements have events on them, wow. The Firefox developer tools are nice.

Outside developer tools Firefox is missing HTML5 directoryReader support and Chrome style screen sharing neither which are in standards, but really really helpful for developers.

The new features are awesome. At the moment I use both DevTools and Firebug.

https://bugzilla.mozilla.org/show_bug.cgi?id=876480, seems like this won't be happening soon.

http://dev.w3.org/2009/dap/file-system/file-dir-sys.html#the...

I primarily use Firefox for browsing, but for development I usually use a mix of Firefox and Chrome. It might be just me, but it's very common when I use the JavaScript debugger in Firefox that it either freezes the site, the debugger, or Firefox itself. That causes me to give up and head to Chrome. I also wish they put a visual queue on the web page when you pause the debugger like Chrome does. Everytime the site get's unresponsive I have to click around few times, wonder what I screwed up, and then realize that the debugger was paused.

> It might be just me, but it's very common when I use the JavaScript debugger in Firefox that it either freezes the site, the debugger, or Firefox itself.

If you have a test case and steps to reproduce, please file a bug! We can't usually fix the bugs we don't know about.

It's just very inconsistent. It just happens sometimes and I either restart firefox or close and open the tab and it goes away. I can try to take a memory dump when that happens. I don't know how useful that might be for you. If I ever get something consistent I will make sure to file a bug.

Thanks for all the amazing work though! nothing beats the visual tools and network traces in Firefox.

Have you tried a fresh install of FF? New profile with no addons and slowly (1 by 1) add your customizations back?

Mozilla: we care about the problems you're facing, unless you're one of the 80+% of people who hate Australis... then fuck you.

I think you may have fixed it since I haven't had a problem in awhile but I sporadically had problems where the debugger didn't trigger on a break-point after awhile in a long debugging session. Is there a way to report heisenbugs like that which isn't going to waste your time?

This is a great question, thanks for asking.

For crashes, definitely submitting the crash report found in about:crashes helps a ton.

Checking the browser console for an error message + stack and pasting that in a bug + description of bad behavior can be useful.

Finally, in extreme cases you can enable all the devtools logging[0] and then run firefox while piping stdout into a log file. This is a firehose of information, but it should hopefully point to the part of the code base that is misbehaving.

[0] https://wiki.mozilla.org/DevTools/Hacking#Enabling_DevTools_...

I've being showing off some of the new advances firefox has being making around the office. These improvements are really starting to turn some heads!

I love using Firefox Developer Tools, but there's a really annoying bug[1] (been around since 2002!) that prevents Django sites from working properly with the Debugger. It's really the only thing that is preventing me from switching to Firefox for development :(

[1] - https://bugzilla.mozilla.org/show_bug.cgi?id=156435

That's a rather dramatic overstatement - it only affects sites which set Vary:cookie and when the user has disabled caching. That ticket is a repeated cycle of people reporting problems which don't reproduce, including the very latest ones.

I've just updated with reproduction steps[1]. The problem appears to be with disabling third party cookies (even though the session cookie is first party). Can you please verify?

[1] - https://bugzilla.mozilla.org/show_bug.cgi?id=156435#c52

One thing which is still missing is the cache viewer. I still need to use an add-on for that when necessary.

What I'd really love to see is debug support for scripts loaded asynchronously with jQuery's $.getScript. Afaik none of the major browsers support this yet.

Nice stuff. I hope chrome dev tools gets these features soon.

I still think Firefox dev tools are subpar compared to Chrome's. For example the lack of a proper cookies listing. I often want to delete a specific cookie when developing. Very easy with the Resources tab in Chrome while a real hassle in Firefox.

Ok, so I'm getting downvoted but why? If there's an easy way to deal with cookies in Firefox then please enlighten me.

I don't know of one, but Firebug has a nice cookie viewer/editor. To be fair, the Chrome cookie tool seems to be useless for anything other than deleting cookies, which is why I keep the EditThisCookie extension installed.

https://chrome.google.com/webstore/detail/editthiscookie/fng...

You can use the `cookie` tool in what's called the "command line". It's been there for quite a while now: https://hacks.mozilla.org/2012/08/new-firefox-command-line-h...

Granted, it's not an actual panel in the toolbox, but it gets the job done.

Try Ctrl-i, right-arrow 3 times, then Alt-k.

Preferences > Privacy > Use custom settings for History > Show Cookies gives you a listing that lets you search by site or cookie name and sort the results, for what that's worth.

It's simpler than even that if you're worried about it on a per-site basis - right click, Page Info, Security, View Cookies. It's the same window, prefiltered by the site you're on.

When talking as complicated as the developer tools it's not helpful to pronounce a sweeping judgement like "subpar" based on a single niche feature. Are the Chrome tools subpar because they lack support for easily seeing which fonts were used on an element?

Fair point, even though I said "for example". There are a lot of other things I think are lacking, mostly UI issues which I find unintuitive, but I wanted to bring up a concrete example which is a real deal breaker for me.

Not only a single feature. Developer tools are worse in almost everything. Last time I used them (few weeks ago) I wanted to throw my rig throught a window after few minutes. Firebug saved the day.

Did you actually file bug reports for specific improvements? I use both heavily and have run into good and bad experiences with each — you have to talk about specific features before you can meaningfully compare anything. Is Responsive Design Mode better or worse than Chrome's debugger? Depends entirely on what I need to do.

In chrome you can see the font used under the "computed style" tab on the right.

(This isn't meant to contradict your point—you were obviously using an arbitrary example—just thought you should know).

If anyone's aware of how, I'd like to know how to do this in Safari web inspector.

Actually that's not correct. The computed styles pane isn't telling you what font is being rendered. The Firefox Font Inspector is telling you what is actually being rendered on the screen. This is impossible to do with IE and Chrome.

Try it out: Specify a font not on your system. Chrome will show you that font while Firefox will tell you what fallback is being uses.

that's not correct.

Chrome will show the truly rendered font from your system - the full name, even (i.e. Verdana Italic).

I've taken a quick screen capture, where I've followed your steps by requesting a non-existent font and causing Chrome to fall back:

http://i.imgur.com/C6IJyF6.png

FYI, I'm using Chrome on OS X..

   Version 38.0.2107.3 dev (64-bit)

Thanks – looks like that was added about a year ago and I obviously haven't needed it in awhile:

https://code.google.com/p/chromium/issues/detail?id=135489

Reply on news.ycombinator.com