= The Simple Explanation = Templetized Trees are an issue because they don't copy their content elements into the DOM. That's pretty disastrous for a DOM based automation tool. This means mozmill can't inspect tree children elements and can't automate interaction with them through the UI interfaces. However, if the tree in question implements some of the standard tree object libraries, then we may have a solution for this. If you're interested in the gory details, read on. = The Details = This means that your standard, run of the mill XUL trees we can automate. It means that if you have subclassed a tree view implementation from nsITreeView AND you also have attached a nsITreeContentView to your created tree, we can automate you. However, if you did not add those to your tree implementation then we can't automate you. Specifically, we need the getItemAtIndex method which resides on the nsITreeContentView to get to you. It tried QI'ing the nsITreeView to an nsITreeContentView, but of course that didn't work (I was out of other ideas, I must admit). So, the net of this is that in order to be testable by mozmill, we need your tree implementation to have both an nsITreeContentView object and a nsITreeView object implemented for it. Unfortunately not all custom-crafted trees implement both objects (places, I'm looking at you -- Dietrich, please tell me I'm wrong here). But for standard XUL trees (and trees that have these interfaces) we should be able to access the DOMElement interfaces of the children elements via this algorthim: <standard recursive search for elements> if (element.tagName == "tree") { for (i=0 i < element.view.rowCount; ++i) { addInspectorListeners(element.contentView.getItemAtIndex(i)); } The "addInspectorListener" is pseudocode for the listeners we attach to elements in order to make the inspector function work so that we can find these elements. Likely this means we'll have to either adapt the "Lookup" elementslib search or create a new elementslib search type for trees that we use once we have a tree. We should also try to determine before doing this whether or not the tree in question implements the "view" and "viewContent" objects, because if it doesn't then our only option is to instruct the tester to use the backend XPCOM interfaces to that content to get the information there. Those nodes are not accessible outside of their trees (at least not as far as I can tell). = Note this will make NO sense unless you've looked at the Songbird DOM = Let's take the songbird example (standard XUL trees) and use the mozmill shell to figure out the elements: // songbird window s = windows[1]; // grab the anon node right above the service pane XUL tree element: sbsvc = s.document.getElementById("sb_servicepane_treepane"); // get it's anon elements anons = s.document.getAnonymousNodes(sbsvc); // the first node is the XUL tree tree = anons[0]; // use the view to get the number of rows of tree children that exist numRows = tree.view.rowCount; // use contentView to grab the DOMElement you want from that specific row. e0 = tree.contentView.getItemAtIndex(0);

(In reply to comment #0) > object implemented for it. Unfortunately not all custom-crafted trees > implement both objects (places, I'm looking at you -- Dietrich, please tell me > I'm wrong here). But for standard XUL trees (and trees that have these Dietrich isn't watching this component. So lets cc him.

Clint, this looks like a blocker especially for creating tests which handle actions in the Library or for Thunderbird folks.

Clint is going to file some toolkit hooks to make this doable in a future release.

Mikeal, please adjust the priority accordingly to the given list. Future would mean somewhat P4 and not a blocker.

It's a P1, we need to fix it as soon as possible, we're just block by work that needs to happen in the platform. Clint will be following up with toolkit bugs.

I'm agreeing with whimboo that this highly blocks Mozmill in TB, besides the modal windows patch. Could the toolkit bugs be linked here (via Depends on / Blocks) so they're trackable?

So, some of the guys at PushToTest are using mozmill with tree views. Basically, inside their tests they make some select() calls in the tree interfaces. Turns out that for most UI there are only a few operations you need to do to the tree before you change another panel and can get all the regular nodes and continue testing. Instead of sitting around being blocked by this maybe we should try digging in and working around some of these problems. It's not ideal but it'll get us automating this stuff and can inform a more general API down the line.

Not a blocker at the moment. Lowering severity to major.

We can do a first step in bug 516997 with a shared module.

The basic problem here is that XBL widgets don't allow us to use lookup strings to access their child nodes. We do not only fail for trees but also all kind of listboxes. The workaround to access any of the childs is to use a construct like the following for now: > var index = 0; > var list = new elementslib.ID(controller.window.document, 'exampleList'); > var elem = new elementslib.Elem(list.getNode().getItemAtIndex(index)); > > controller.click(elem); As talked with Clint on IRC we should check how the DOM inspector is able to fetch those child nodes.

(In reply to comment #12) > As talked with Clint on IRC we should check how the DOM inspector is able to > fetch those child nodes. I don't know if you ever looked into it further, but DOM Inspector is able to inspect anonymous content because its view is just a blob in layout/ with the requisite privileges. I factored out the part that inDOMView uses to get at anonymous content so Chromebug could do the same (I don't know if anything has come of it, though). In any case, that part's in inIDOMUtils, so now it's scriptable.

As for comment 0, it's symptomatic of nsITreeView being ill-suited for anyone hoping to achieve decent MVC with it. bug 317904

Given that we have node-collector on our side, I don't see that his bug is that important for us right now.

Mozmill will reach its end of life soon. We are currently working on getting all the tests for Firefox ported to Marionette. For status updates please see bug 1080766.