581339 - Inspector object history

Status: RESOLVED WONTFIX

(DevTools :: General, defect)

Description

[Kevin Dangoor]

The inspector keeps track of a number of nodes visited. These can be retraced through the Next/Previous buttons on the inspector's HTML panel's toolbar. In addition, these should set the Firebug Command Line API variables $0, $1, etc. for easy access in the Console.

Someone using the Inspector could, for example, inspect a series of nodes related to a particular control on a webpage. Then, in the console, they could programmatically access them using the $0, $1 mnemonics and then manipulate the DOM objects, print their properties or trigger the inspector.

In summary, implementing this feature involves:

1. keep track of the recent DOM nodes accessed
2. provide these nodes to the console for easy access/manipulation
3. provide UI for going back/forward between these nodes in the Inspector

Comment 1

[Julian Viereck]

Depends on bug 575789 (JSTerm: helper functions).

Comment 2

[Rob Campbell [:rc] (:robcee)]

julian, I would change the order of the dependencies here. I think this bug should block bug 575789, not depend on it.

Comment 3

[Julian Viereck]

(In reply to comment #2)
> julian, I would change the order of the dependencies here. I think this bug
> should block bug 575789, not depend on it.

The reason why I said this bug depends on bug 575789 is, because that bug implements some helper functions ($, dir, print...). If we get these added, we should have a pattern to implement the $0 and $1 helper functions as well that Kevin mentioned in comment 0.

Implementing the helper functions (aka bug 575789) is not dependent on this bug. This bug is about making an connection between the WebConsole and the Inspector, but doesn't block the implementation of helper functions in general.

Rob, if you think this makes sense, please switch the block/depends for bug 575789 around again.

Comment 4

[Kevin Dangoor]

In my opinion, this bug and bug 575789 probably shouldn't have a blocking relationship at all. Just having helper functions in the console is a useful thing and does not necessarily require providing extensibility in order to be useful (though I'll grant that extensibility *is* useful there).

Similarly, inspector object history can be useful even without integration with the console.

So, I'd rather that the two were disjoint and, if anything, we create another bug for adding some sort of namespace extensibility to the console. That gives us more flexibility in what we choose to implement in this round.

Comment 5

[David Dahl :ddahl]

(In reply to comment #4)
> So, I'd rather that the two were disjoint and, if anything, we create another
> bug for adding some sort of namespace extensibility to the console. That gives
> us more flexibility in what we choose to implement in this round.

Sounds like a plan.

Comment 6

[Rob Campbell [:rc] (:robcee)]

(In reply to comment #4)
> In my opinion, this bug and bug 575789 probably shouldn't have a blocking
> relationship at all. Just having helper functions in the console is a useful
> thing and does not necessarily require providing extensibility in order to be
> useful (though I'll grant that extensibility *is* useful there).
> 
> Similarly, inspector object history can be useful even without integration with
> the console.
> 
> So, I'd rather that the two were disjoint and, if anything, we create another
> bug for adding some sort of namespace extensibility to the console. That gives
> us more flexibility in what we choose to implement in this round.

No longer blocks: 575789Whiteboard: [kd4b4]

wfm.

Comment 7

[Rob Campbell [:rc] (:robcee)]

closing

filter on PEGASUS.