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.
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.
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.
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).
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.
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.
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?
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.
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 :(
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?
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.
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.
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?
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.
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.
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.
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.
