When I inspect accessible tree view for non-chrome document (like web page) then I get may errors related with getCellText() method of tree view. I close DOMi and I switch to console to copy error message but firefox hangs. It sounds chrome's tree view can't operate with non-chrome documents, possibly it's security related issue. Any thoughts?

the bug is presented on windows as well, so I guess it crossplatform issue, changing OS. the bug may be related with bug 450528.

Boris, could you look at this bug and bug 450528? It's obviously security stuff and really I don't get why our chrome-hosted tree views may have some security restriction. Could you cc guys who can help here?

Some steps to reproduce would be a good start. I don't see any obvious "accessible tree" in DOM Inspector. It would also help to point to whatever code is involved (e.g. the treeview in question).

(In reply to comment #3) > Some steps to reproduce would be a good start. I don't see any obvious > "accessible tree" in DOM Inspector. So, steps to reproduce: 1) start DOM Inspector for Firefox. 2) DOM Inspector loads automatically the content page open in Firefox. 3) Click on the button to change view of the left panel. Available tree views should be: DOM Nodes, Stylesheet, JavaScript Object, Accessible Events, Accessible Tree 4) Choose "accessible tree" view and navigate through the tree for example by keyboard 5) When tree item is selected then text of "Node Name" cell is disappeared, run the error console to see exception > It would also help to point to whatever code is involved (e.g. the treeview in > question). > Three view for "DOM Nodes" view is implemented in layout/inpsector by C++ and it's created in http://hg.mozilla.org/dom-inspector/index.cgi/file/661d13c545fd/resources/content/viewers/dom/dom.js#l86 Tree view for "accessible Tree" is implemented by JS (http://hg.mozilla.org/dom-inspector/index.cgi/file/661d13c545fd/resources/content/viewers/accessibleTree/accessibleTree.js#l190). So the problem, we can't work with DOM (we get an exception) inside the 'select' event listener (http://hg.mozilla.org/dom-inspector/index.cgi/file/661d13c545fd/resources/content/viewers/accessibleTree/accessibleTree.js#l158) I think.

example of exception is Error: Permission denied for <file://> to create wrapper for object of class UnnamedClass Source File: XPCSafeJSObjectWrapper.cpp Line: 445

> Available tree views should be: DOM Nodes, Stylesheet, JavaScript Object, > Accessible Events, Accessible Tree I only have the first three of those over here, as far as I can tell.

What is your OS? For example, if you are on OS X then you should add "ac_add_options --enable-accessibility" line to you .mozconfig because accessibility is not enabled by default there.

Ah, that was it. Well, this is kinda fun. This code is basically doing: node.setUserData("accessible", aAccessible, null); on a DOM node (HTMLDocument, but that's not as important). The thing is that |node| in this case is actually the wrappedJSObject of a XPCNativeWrapper (presumably because DOMI in general uses the unwrapped object so the JS view will work? I have no idea). In any case, it's an XPCSafeJSObjectWrapper. So we call the wrapped setUserData on it, and that calls through to the native code. But setUserData returns the old value as an nsIVariant. So we have to wrap that. When we go to wrap it, the live JS stack frame is the one from the XPCSafeJSObjectWrapper. Since the accessible object (which is what we're wrapping) doesn't implement any special security hooks to allow untrusted script to wrap it, you get the exception. Blake, is this really the right behavior in this case for the SafeJSObjectWrapper? I guess so....

This is major issue but there is no activity on the bug. I suggest to consider workaround patch until original issue is not fixed.

Comment on attachment 396982 [details] [diff] [review] workaround patch r=sdwilsh Yeah, I'm fine with this.

Comment on attachment 396982 [details] [diff] [review] workaround patch >+ DOMNode.accessible = accessNode; >+ DOMNode.accessibleEvent = event; Please don't use obvious variable names, they could conflict with web content. As an example, DOMNode[" accessible event "] would be less likely to conflict.

addressed Neil's comments

landed workaround patch - http://hg.mozilla.org/dom-inspector/rev/653c0e6ca601, leaving this bug open to fix original problem.

Alex, going through old bugs. Given that DomI is discontinued, I assume this is no longer relevant?

(In reply to Marco Zehe (:MarcoZ) from comment #14) > Alex, going through old bugs. Given that DomI is discontinued, I assume this > is no longer relevant? yeah, no longer relevant