Pretty self-explanatory.

By link you mean "Jump to definition"? We could also show the function source in the variables view, but my concern is that it clutters up the tree and may take too much space.

Yes, I mean "Jump to definition". As far as I could see, this isn't available now.

Indeed. I think we could do this with the parser API, although we'd need to parse all the sources first, since a function could be defined in a different script. Probably not that big'a'deal since the stuff in reflect.jsm is magical. I see this as a shortcut for bug 762160.

P3 because it's depending on a bunch of stuff.

Relying on the parser API isn't a failproof method. Functions with the same name may be defined anywhere, and inferring which is the right one proved incredibly hard. This isn't a problem for bug 762160, since a list is acceptable in that case, but it's probably an issue for this bug, since I'd expect accurate results from the variables view. AFAIK, the protocol doesn't carry location information (nor the source text) for functions, not as part of their environment, and also not when getting their prototype and properties. I can't see how we can make this more accurate than providing a list of functions as in bug 762160.

Debugger.Objects that are functions have a |script| property in their prototype pointing to their Debugger.Script. Jim, can we add the script URL in a |script| property to function grips, in order to implement this feature? Or even better, since we'll get bug 795368 soon, maybe add a |source| property with a SourceForm to it?

(In reply to Panos Astithas [:past] from comment #6) That would be exceptional from my perspective.

The protocol should *definitely* provide a way to follow that link. Certainly Debugger has all the data needed to do so.

(In reply to Panos Astithas [:past] from comment #6) > Debugger.Objects that are functions have a |script| property in their > prototype pointing to their Debugger.Script. Jim, can we add the script URL > in a |script| property to function grips, in order to implement this > feature? Or even better, since we'll get bug 795368 soon, maybe add a > |source| property with a SourceForm to it? In the protocol's terminology, function grips should have a "location" property whose value is the source location of the start of the function. The protocol defines what "source location" forms look like. This information is easy to produce. What would the UI be? Could we make function names look clickable somehow? Or what?

(In reply to Jim Blandy :jimb from comment #9) > What would the UI be? Could we make function names look clickable somehow? > Or what? That would conflict with the current click-to-expand functionality (although the treetwisty serves the same role, it's generally best to have a wider clickable area for expansion). Accel+click could work, but I worry it's not discoverable enough. Inspector solves this problem pretty gracefully in the Rule view by providing a link to the selector's location in the css via a clickable url aligned on the right, on the same line with the selector itself.

I won't be able to look at this very soon, sorry!

Moving stuff to the Object Inspector component. Filter on COSMICMIGRAINE.

Created https://github.com/devtools-html/devtools-core/issues/802 to consume a given "jumpLocation" by Reps / ObjectInspector. Jim, do you know if we have access to the definition location for non-function objects ? If not, maybe we can re-purpose this bug to do this work (or at least to expose it in the grip).

Including the allocation site in the grip would be really cool. Without setting some sort of flag, we don't collect the allocation location for arbitrary objects. Promises save the stack at the point of their allocation; this is available via the `promiseAllocationSite` property of the Debugger.Object. This data is collected if the page was a debuggee when the Promise was created, or if the `asyncStack` option is set on the JSContext (dom.workers.options.asyncstack, for workers; javascript.options.asyncstack for other code): Here's the function that decides whether to save a new Promise's creation site: https://searchfox.org/mozilla-central/rev/f0ab0b072ae090f11d6b02b7cf1e0829b4f08882/js/src/builtin/Promise.cpp#165-169 If a Debugger's allocation site tracking is enabled (by setting dbg.memory.trackingAllocationSites and dbg.memory.allocationSamplingProbability appropriately), then a Debugger.Object's allocationSite property holds a stack captured when the object was created. Full rules for allocation site tracking: https://developer.mozilla.org/en-US/docs/Tools/Debugger-API/Debugger.Memory#Allocation_Site_Tracking