The first time I use it it works but I get the following errors: Error: doc is undefined Source File: chrome://inspector/content/viewers/dom/dom.js Line: 678 Error: doc is undefined Source File: chrome://inspector/content/viewers/dom/dom.js Line: 716 The second time I use it I get the same errors but it doesn't work, the toolbar button stays depressed and the new node isn't selected in the tree.

I think this is due to XPCNativeWrappers. Here's the stack trace for JS: #0: function DVr_FindDocuments(aArray=Array:{0}, aDoc=void:void) in <chrome://inspector/content/viewers/dom/dom.js> line 1016 #1: function DVr_AddKidsToArray(aArray=Array:{0}, aKids=XPCNativeWrapper:{4}) in <chrome://inspector/content/viewers/dom/dom.js> line 1032 #2: function DVr_FindDocuments(aArray=Array:{0}, aDoc=XPCNativeWrapper:{133}) in <chrome://inspector/content/viewers/dom/dom.js> line 1019 #3: function DVr_GetAllDocuments() in <chrome://inspector/content/viewers/dom/dom.js> line 1010 #4: function DVr_StartSelectByClick() in <chrome://inspector/content/viewers/dom/dom.js> line 674 #5: function () in <chrome://inspector/content/viewers/dom/dom.js> line 667 (Note that #5 is actually from a setTimeOut in DVr_SelectByClick.) addKidsToArray: function DVr_AddKidsToArray(aKids, aArray) { for (var i = 0; i < aKids.length; ++i) { try { aArray.push(aKids[i].contentDocument); // Now recurse down into the kid and look for documents there this.findDocuments(aKids[i].contentDocument, aArray); <-# } catch (ex) { // if we can't access the content document, skip it } } }, aKids[i] on the marked line is a XUL browser which is purporting to have no contentDocument. I guess it's because it's an XBL getter, and as far as the wrapper is concerned, the browser is just a XULElement.

To reiterate: aKids[i] is a browser (it's the browser comprising the add-on manager's discovery pane, in other words, the pane you get when you have "Get Add-ons" selected), but here it's only known as a plain XULElement; it doesn't know about its binding. If I do "contentDocument" in aKids[i] I get false. The following returns true, though: "contentDocument" in aKids[i].wrappedJSObject Oddly enough, this works perfectly well on other documents that have browsers, e.g., the tab browsers in browser.xul, and when inspecting other DOM Inspector instances. One thing I do notice, though, is that if you load chrome://inspector/content/inspector.xul in Firefox, via the address bar, a similar thing *does* occur, this time on ifBrowser, which is the lower browser pane in DOM Inspector. It's a type="content-primary" browser. Note that it doesn't choke on the two browsers comprising the document and object panes though. Naturally, they aren't content type browsers. Could the issue of not being able to see the browser binding arise from the existence of them being content browsers while loaded within the Firefox content area?

(In reply to comment #2) > Note that it doesn't choke on the two browsers comprising the document and > object panes though. Scratch that observation. It's true, but it shouldn't be expected to choke there, because those browsers aren't ever subjected to that code path since they're never put into aKids. (aKids is built by a getElementsByTagNameNS for xul browsers; the browsers comprising the document and object panes are anonymous, so they shouldn't be expected to be returned.)

> Could the issue of not being able to see the browser binding arise from the > existence of them being content browsers while loaded within the Firefox > content area? Yes, of course. Wrapperization is based on window type; if you have code running in a chrome window that touches objects from a content window (which is what about:addons is loaded as; usual brokenness, blah, blah) then you will get XPCNativeWrappers. And XPCNativeWrappers are designed to hide JS expando properties. And XBL-defined properties are JS expando properties. If you really want to work around this, you can probably do it via QI to nsIFrameLoaderOwner, getting the nsIFrameLoader, then getting the docshell, etc. But it'd be really nice if about:addons just didn't get loaded in a type="content" docshell...

(In reply to comment #4) > it'd be really nice if about:addons just didn't get loaded in a > type="content" docshell... Although extensions could do something similar, and the DOM Inspector really should be able to handle it. Did something change here, though? The add-ons manager is no longer exhibiting this behavior, about:addons is still loaded in a content browser, and select by click functions as expected there. That indicates the get for contentDocument on the browser was successful.

> Although extensions could do something similar, No, you don't understand. If the Firefox UI were not doing that crap, I'd turn off the ability to turn it off on the Gecko level (we've wanted to do that for literally years), and we would never have that sort of problem. The question of whether you want to support this in DOMi is, of course, orthogonal. > That indicates the get for contentDocument on the browser was successful. That's ... somewhat worrisome. Blake?

Bulk close. This component is no longer supported or maintained. https://bugzilla.mozilla.org/show_bug.cgi?id=1499023

Bulk close. This component is no longer supported or maintained. https://bugzilla.mozilla.org/show_bug.cgi?id=1499023