Open Bug 704094 Opened 9 years ago Updated 1 year ago
Add a DOM View to the inspector
Allow an easy way to view the DOM for a node with a DOM button. The new sidebar would display the same information currently shown by: <highlight><control-shift-K>inspect($0)
Yes, I think it would be useful to show any properties of the object the highlighter points to. (Sorry about the block -- select error trying to copy the bug number of the Highlighter meta bug.)
So the plan is to move the JS Object inspector from its own window into the Web Console (bug 704180).
(In reply to Paul Rouget [:paul] from comment #3) > So the plan is to move the JS Object inspector from its own window into the > Web Console (bug 704180). for web console inspected objects. I don't think that applies to this bug. Maybe this should be next to the HTML view?
Well, actually, opening the js-obj-view in the Console if opened from the Console, and in the sidebar if opened from the highlighter makes sense.
(In reply to Rob Campbell [:rc] (robcee) from comment #4) > Maybe this should be next to the HTML view? You mean splitting the HTML view in two? I think it would be better to have it in the sidebar.
except the sidebar is labeled "Style" currently. I also think, since we have a grouping of style tools in the sidebar, it might make more sense to put a "DOM Object" viewer into the same panel as the HTML tree. Or we could pop it up separately as we do now as long as we don't get into more xul panel bugs. One of the reasons we didn't include an Object button in the Highlighter was because I was selling "Annotations" as a possible way to get information about the object into the Highlighter view. Some people deemed the Object button as "too fringe", though I kind of disagreed at the time. There is a workaround available if you open the Web Console and type $0 or inspect($0) to open the property viewer directly.
(In reply to Rob Campbell [:rc] (robcee) from comment #8) > except the sidebar is labeled "Style" currently. I also think, since we have > a grouping of style tools in the sidebar, it might make more sense to put a > "DOM Object" viewer into the same panel as the HTML tree. Or we could pop it > up separately as we do now as long as we don't get into more xul panel bugs. This tool doesn't have a name yet, but I don't think it's a DOM-only tool. It's a bit more general (we can inspect the whole JS structure, not just the DOM methods/properties). I would call it JS Object View. This JS Object View can be open in the Web Console (`inspect(window)`). This will happen in bug 704180. Sounds like we want to have a button that will inspect the node too (this bug). We can simply open this tool in the Web Console since we will get inline-inspect working. But: a) from the inspector, the user probably doesn't want to have the whole Web Console; b) this view would fit better in a vertical view. So we need to find a better slot for it. If I'm not mistaken... if we would have had the modular sidebar (from where we could dock/undock tools, and maybe stack tools, with an accordion), we would just add it there. But we don't have this modular sidebar. For now, we have a style-specific sidebar. We could move it into the HTML Panel. But: a) It's a horizontal view; b) We will have to move it the sidebar once it will get the modular sidebar. I see 3 options: a) We open the Web Console when the user click on the button. It's horizontal, but at least, we won't have to "kill" the feature when we will be able to host the JS Object view into the future modular sidebar; b) We hide the style sidebar, and create a JS sidebar; c) We start working on the modular sidebar now.
triage, filter on centaur
Priority: -- → P2
We want to move the buttons inside the sidebar. See bug 717929.
Summary: [highlighter] Add DOM button next to HTML and Style button → Add a DOM View to the inspector
(P3, as discussed with Kevin)
Priority: P2 → P3
The Toolbox + Sidebar.jsm makes things much easier. Bug triage, filter on PINKISBEAUTIFUL
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 817547
Sorry sorry, wrong bug!
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
Probably the most irritating thing for most Firebug users is that we have no DOM tab. In Firebug I can easily inspect an object and click on the DOM tab (In fact, I can use the inspector whilst the DOM tab is open, which makes it very easy to select nodes. Firebug also allows me to right-click an HTML node and "Inspect in DOM panel." In our native tools I have to open a scratchpad or the web console, use a selector to get a node and then click Scratchpad's "Inspect" button. This is hardly discoverable nor as simple to use as Firebug's DOM panel.
The VariablesView is a pretty self-contained widget now, so using it inside the inspector shouldn't be too hard.
Depends on: 918710
I will try to take a look at this one. It would indeed be a pretty good addition to our tools. I've looked at the code a bit and the only unclear part that I'll look into now is how to get an objectActor grip for a dom node in the inspector. Other than that, it should be pretty straight forward with the VariablesView. The other thing is we have 4 tabs in the sidepanel already, this would be a 5th! We might need some re-thinking here. @darrin: thoughts on this?
Assignee: nobody → pbrosset
The obvious thing would be to show the DOM panel where the Fonts tab is and to have an ellipse button to show less useful tools (e.g. Fonts). We need something like that anyway as the side panel pushes tabs off to the right when it is too narrow. Darrin may have something better though.
When it comes to actually retrieving properties from the currently selected node, I'm wondering what's the best course of action. On one side we have the DOM view that will live in the inspector, where we have a reference to the currently selected NodeFront. And on the other side, we have the VariableView widget that works well with ObjectActor's grips. We could: (a) implement a new WalkerActor method that, based on the passed node, would send back the grip. However, this requires to have a ThreadActor (see http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/server/actors/script.js#2832) which the Walker does not have. (b) alternatively, the new WalkerActor method could simply send a new response packet containing the list of key/value pairs for all of the node's properties. This way, we wouldn't use the VariableView's ability to work with grips at all. (c) or find a way to call the webconsole's server which does the job already (i.e. when you click on the output link for a DOM node). I'm leaning towards (a) but haven't yet been able to figure out how to make it happen.
(c) isn't very practical as it requires a "evaluateJS" packet type which takes a string input whereas we have a DOM node front here.
Mihai can elaborate more on this, but you don't need much machinery to use the debugger APIs with object actors. Unfortunately this is not well documented, but see how WebConsoleActor creates ObjectActors internally (pretending to be a ThreadActor by mocking _gripDepth and createValueGrip mostly). If your actor implements the right methods, the code that will give you the grip should roughly be: let grip = actor.createValueGrip(actor.makeDebuggeeValue(domObject));
Thanks Panos for the help. I've managed to implement the premise of solution (a). I now have problems related to how the VariablesView widget fetches properties, but this seems related to the actorpool which I need to maintain on my side. No need to needinfo Mihai anymore for now. I'll probably come back with more questions later though :)
Patrick, I believe solution (a) is the one you should continue work on, as you are already doing. As Panos pointed out, you only need _gripDepth and createValueGrip(). For createValueGrip() I maintain my own actor pool, because the lifetime of object actors is different in the webconsole, when compared to debugging. During debugging you have thread-lifetime and pause-lifetime actors. It would be nice if you could reuse the console actor, to avoid code duplication.
Dave, do you have suggestions as to how I could reuse the WebConsoleActor's ability to retrieve object actor grips from the inspector actor? It seems to me that the inspector, being a protocol.js type actor, does not have access to the globally loaded actors.
Status update: I've managed to get the DOM view sidebar working but it's a bit of a hack right now. It works by acting as a ThreadActor, just like the WebConsoleActor does, and in doing so, can easily create ObjectActorGrips that have the thread lifetime instead. The reason it's hacky right now is that from the WalkerActor I need access to 2 classes defined in script.js: ThreadActor and ObjectActor. Although the WebConsoleActor has access to these classes from the global scope, the WalkerActor does not.
I think you are right, protocol.js-based actors are loaded in separate globals, so perhaps it's time we split the common bits of script.js into separate objects that can be used by both old-style actors (script.js, webconsole.js) and modern ones, like inspector.js. Moving the ObjectActor to an object.js module sounds straightforward and a good place to start.
Darrin, here's a work in progress to add an ellipsis to the sidebar tabbox in case there's not enough room: http://www.youtube.com/watch?v=K2EHMZK9ybU As you suggested, it would be nice to have an icon for this.
Attaching my current patches for this bug. They're not ready for review just yet, but I'm getting there. Here's a status of the progress: part 1: - New "DOM" sidebar panel in the inspector. - Reacts as the other panels do: refresh on new selection, empties if no node selected. - Also reloads on node mutation. - Uses telemetry. - Is localized. - Uses the VariablesView widget to display the properties. - Goes to the server to translate the NodeFront into an ObjectActorGrip for the VariablesView to work (it does this similarly to how the WebConsole does it: that is by playing the role of the ThreadActor, by overriding some of its methods and managing its own actor pool). This part isn't very very nice, but it turns out protocol.js actors aren't loaded in the server's global scope, so they don't have access to all actors by default. So what I did was split script.js in several files as I could. For instance, ObjectActor is now in a separate module that can be required by other actors. But I wasn't able to split the ThreadActor in a separate module as it requires simply too many dependencies. part 2: - Adds a new option to the ToolSidebar widget that shows an allTabs menu to the right when there's not enough space to let all tabs be visible. This menu contains a drop-down of all tabs. - Makes the netmonitor also use ToolSidebar so it has the same feature. For this, I had to improve again ToolSidebar in a way that it now also works with existing <tab> elements. part 3: - Adds a simple test. I need to keep working on it and add new tests for the inspector and netmonitor sidebars.
Comment on attachment 8363914 [details] [diff] [review] bug704094-inspector-domview-part1-Adds-the-sidebar.patch Mihai, getting a review on the part that returns actor grips would be awesome since you did this for the webconsole.
(In reply to Patrick Brosset [:pbrosset] from comment #37) > Comment on attachment 8363914 [details] [diff] [review] > bug704094-inspector-domview-part1-Adds-the-sidebar.patch > > Mihai, getting a review on the part that returns actor grips would be > awesome since you did this for the webconsole. That part seems fine. Is the threadActor always available on the tabActor? I understand these are wip patches, so dont worry about all the comments, I noted them so we dont forget things with the next update.
NIing Mike on this old bug which I never finished ... Getting this landed would be great! For info, I also started bug 1101569 to make the sidebar easier to use when there are many tabs. So attachment 8363915 [details] [diff] [review] should be ignored here.
I don't have time to work on this at the moment. I would prefer a sidebar than our current context menu implementation because I think it would be more discoverable and useable.
Resetting assignee due to lack of activity.
Assignee: ntim.bugs → nobody
Status: ASSIGNED → NEW
I have a colleague that still uses an ancient build of Firefox so they can us Firebug and the dom properties panel. In Fx, currently, the right-click, "show dom properties" gets kind of close. In Firebug, that panel was on the right in a tabbed interface, and in Fx, it's in a panel below (using the console), but that's a minor issue. The real issue is that I cannot seem to edit the dom properties in the "inspect($0)" anymore. I think I used to be able to in Fx, but I know I was able to in Firebug DOM Properties. Fx dev tools is better than Firebug in most ways, now, but this seems a major oversight to me. It was one of the best features of Firebug.
Depends on: 1534982
Priority: P3 → P5
You need to log in before you can comment on or make changes to this bug.