Bug 80383 – Web Inspector: "Skip this Frame" Feature

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Web Inspector (Deprecated)

[Yehuda Katz]

In web frameworks, it's common to have methods whose sole purpose is to dispatch to another method.

Imagine a simple event dispatcher like this:

    var hub = {
      events: {},
      bind: function(name, fn) {
        var events = this.events[name] = this.events[name] || [];
        events.push(fn);
      },

      trigger: function(name) {
        var events = this.events[name] || [];
        events.forEach(function(fn) { fn(); });
      }
    };

When an event is triggered, the code path will go through the `trigger` method and into each callback. However, when debugging code, having to manually walk across and down the trigger frame can be extremely annoying. In the absence of an exception in the trigger method, it simply doesn't matter.

Other common examples of this pattern:

* `get` and `set` methods in Ember.js that end up in "computed properties". From the perspective of the person debugging code, they want to jump directly from the `get` call site into the computed property.
* `super` in Ember.js and jQuery UI: Super can be implemented via a wrapper around a method dispatch that sets a `_super` property on the object and removes it once the dispatch is done. This means that calling into a method must first walk through the wrapper code. Again, this code is irrelevant.

I'm most familiar with the Ember.js cases, but almost every framework has some code (often event dispatching) that is used purely for internal dispatching and is irrelevant from the perspective of the framework consumer (unless an exception happens inside that code).

I would like to propose that frameworks be able to mark frames as skippable (maybe something like `fn.skipInDebugger = true`), which would cause the debugger to step through them when stepping was used. For advanced users, perhaps there could be an option to disable frame skipping.

[Rafael Weinstein]

Any feelings about this feature request?

Yehuda represents a large portion of developer mind share. We really want this kind of feedback. I think it'd go a long way, even just to entertain the idea and communicate something about likely implementation complexity and relative priority given other work, as a first step.

[Paul Irish]

I have been hearing similar feedback more and more; it's challenging to debug though 12 layers of script. This would provide much better ergonomics in debugging web apps.

[Brian Grinstead]

This would a great way to improve the debugging experience.

I'd like to chime in with a request I have along the same lines.  On the "Elements" panel, "Event Listener" section, it usually ends up linking to a framework's internal functions as the callback function (assuming you are using a DOM framework to bind events).  This takes me into the middle of library code - not the actual callback I am interested in.

I had an idea for a way to see the more useful function, by keeping track of which functions originally caused the framework to add the event listener.  Essentially a stack trace of the original event binding (really only the file name, and line numbers), that allow me to click into the function that actually caused the DOM framework to add the event listener.

Please check out a more detailed summary (along with screenshots) on my post here: http://www.briangrinstead.com/blog/devtools-feature-request-show-stack-trace-in-event-listeners

Could there be some overlap here?

[Blaze Burg]

Hi Yehuda,

What do you think of script blackboxing as implemented in Firefox? I think it provides most of the same functionality, except that it is per-file IIRC.

Marking as duplicate for now.

*** This bug has been marked as a duplicate of bug 17240 ***

[Yehuda Katz]

Brian,

I worked with Firefox on this feature and opened up a number of subsequent requests for more granular control over the black-boxing.

For example, when I'm debugging Ember itself, even though I want to step through Ember source, I still want to jump through our implementation of forEach and the extra function wrapper we need to create for super (which are *never* the source of bugs).

My ideal implementation would support whole-file blackboxing, blackboxing based on an identifier provided by the script (//# blackboxId=ember), and finally per-function blackboxing via sourcemaps (or if that's not possible, via dynamic tagging).