~robcee/ more than just sandwiches

In the trees

Last week I managed to get the Inspector’s new tree panel working locally. It was a good chunk of work, incorporating about 2000 lines of DOMPlate, converted to a new JavaScript Code Module and another 1000 or so lines of JavaScript and CSS from Firebug. This morning I finished up the styling fixes for Windows and Linux and have it running on all three platforms. Mostly.

To be sure, there are some bugs left. Clicking the twisty images still doesn’t expand and collapse the trees – you need to click on the tag to do that. It’s still behaving funny with iframes. I still need to revise the styling for the tree panel and other panels to make it look like I want. I need to add some keyboard controls…

All of this will need bugs filed and patches written. If you’d like to help, please feel free to file bugs on the Firefox::Devtools component. Make sure to use Inspector in the subject or whiteboard so we can track it. We also have a #devtools IRC channel on irc.mozilla.org if you’d like to pop in and say hi.

Other bits I have left to do include verifying my existing test cases and writing a few new ones. There’s a lot of debugging code I need to strip out and lastly, I’ll need to rebase my patches against current mozilla-central and roll it all up into a nice tidy patch for my reviewer victim… I mean friend. Before that though, I hope to churn out some try builds tomorrow or Wednesday for people to play with.

If you want to check out the source and build your own, it’s living in http://hg.mozilla.org/users/rcampbell_mozilla.com/mozilla-inspector-2/. Careful, it’s fluxy!

So why domplate? Last I checked, jjb felt that it was an underdocumented mess. In addition, my profiles show it to be a serious performance drag when it’s active….

I thought the point here was to add an improved DOM inspector, but from what I see in your screenshot it looks like you are adding CSS and Script debugging.

Are you planning to implement Firebug inside of Firefox source? If you are there seems very little point in us working on Firebug when we could be helping you implement this.

Boris: I looked at a lot of widgets when trying to figure out how to do this. The XUL tree widget, jsTree with jQuery, YUI, Dojo, some code editors… None of them were exactly what I wanted so there was going to be a bunch of work to shoe-horn them in. Also, they carried around a lot of cross-platform baggage I wasn’t super comfortable putting into the browser.

Firebug itself is pretty poorly-documented at the core level, though the extension API has gotten about a million times better from Honza and JJB’s efforts to improve extensibility. Domplate isn’t much worse than the rest of it though it is pretty complicated to figure out initially. It’s “slow” because it uses a lot of recursion. On the upside, we have a good performance test for the JS team.

Mike: This thing I’m working on is not a debugger. I thought about scrubbing out that “Debug” button on the toolstrip because I was worried people would think that. It’s for my own use debugging the tree widget — currently it’s wired-up to dump the contents of it to the console.

We’re not planning on implementing all of Firebug, but a couple of important features like Inspector and a Console. We’re hoping to make them a little different from what’s already out there. Definitely planning on making CSS editing and tweaking a little different. It’s still early stages for the Inspector so it if it looks a little familiar, that’s just where we’re at.

I don’t want to steal you away from Firebug but I’d love to work with you on this.

robcee, when I was looking at domplate it was slow because it was doing stupid things of all sorts with the DOM, not because it “uses recursion”. In the tests I was looking at it was being something like 5x to 10x overhead (as in, slowed down the page rendering by a factor of 5 to 10).

As in, we can optimize all we want but if you want something that will actually show things reasonably expeditiously domplate is the wrong tool for the job: it’s not designed to do that.

Does XUL really not have a rich widget with twisties that does what we need here without the performance penalties?

To be clear, I understand that using domplate is the easy way forward right now. I just think we should plan up front to stop using it, and not over-rely on its particulars.

hey Boris,

When you say it “slowed down the page rendering by a factor of [x]“, did you mean the content page or the tree representation? I know it’s heavy. It does a lot of seemingly extraneous tree walking to expand and collapse nodes.

In any case, as you surmised, it was an “easy” way forward for me, despite being not very easy. It’s definitely not the final solution I’d like to have, however and think at some point down the road we should replace it with something we like better.

As for the XUL tree widget, it wasn’t a great fit. The closest Neil Deakin suggested was a combination of the current tree widget with some extra patches to provide different row styling. It still looked like it would have been a lot of work to make it do what I wanted.

See bug 441414 for details.

> When you say it “slowed down the page rendering by a
> factor of [x]“, did you mean the content page or the
> tree representation?

The pages in question were doing animations. The frame rate of the animations dropped by a factor of 5-10 when Firebug’s domplate-based tree view was open. Profiling showed all the time spent in the domplate code.

That’s interesting and makes sense, I think. Firebug installs a bunch of listeners into the page’s document and watches for updates to the DOM and style rules. On such updates, it can trigger a cascade of DOMPlate-related construction. Animations could be fairly brutal with that enabled.

We might be able to add a checkbox or something to the inspector to enable live updating and a refresh button to update the view when that’s not enabled.

Thanks for mentioning this!