Loading a xul containing a outliner goes fine, but one can't select. This is broken, because mozilla/xpfe/global/resources/content/bindings/outliner.xml:27 can't create the wrapper. I changed the getter of outlinerBoxObject to say onget="var retVal = this.boxObject.QueryInterface(Components.interfaces.nsIOutlinerBoxObject); dump('|'+retVal+'|'); return retVal;" and get the following when selecting a row in extensions/transformiix/resources/buster/buster.xul: |[xpconnect wrapped BoxObject @ 0x767800]|blank Warning prev sibling is not in our list!!!Document file:///tmp/mozilla/extensions/transformiix/resources/buster/buster.xul loaded successfully JavaScript error: line 0: uncaught exception: Permission denied to create wrapper for object When I add the dump before the access to boxObject, it get's printed. Axel

You can try to reproduce this by loading mozilla/extensions/transformiix/resources/buster/buster.xul. I'm going to attach a stack trace for the failing security check. aObj is an nsXULElement. If you get hit by the "Node is not defined" assertion, try replacing Node.ELEMENT_NODE in mozilla/extensions/transformiix/resources/buster/xulTxTool.js with Components.interfaces.nsIDOMNode.ELEMENT_NODE. I'm a bit at a loss where the bug is exactly.

Hmm, the way to reproduce :-): open the file, it will load data in the outliner view (this might take a while). Once you see the rows displayed, click on a row, that's where you'll see JavaScript error: line 0: uncaught exception: Permission denied to create wrapper for object

I had to add DOM ClassInfo to nsOutlinerBoxObject, to our OulinerView implemented in JS (plus add the QueryInterface implementation for that class) and remove a QueryInterface in outliner.xml. That last one is a bit strange. Why would a QI in JS in an XBL binding (loaded from chrome) be denied? Just because we use an outliner from within a file:// XUL file? Seems wrong to me.

XBL runs with the permissions of the document that loads it. There's a bug on finding some way to give XBL more permissions, but no one has yet worked out a way to do so. The problem being, of course, that Web pages need to be able to load chrome bindings (e.g., textfields for example), but they can't be allowed to take advantage of the godlike powers that the binding would have if it got permissions based off its location rather than the document it's used in.

Peter, why does xulTxTools.js need UniversalXPConnect privileges? If it's running from chrome, that shouldn't be required. Is it a testcase run from the Web?

Hyatt, I see the problem, thanks for explaining. Mitch, this (our test automation) is loaded from a file:// URL. I merely moved the UniversalXPConnect privileges up because I have a problem using Node.ELEMENT_NODE, it seems I need UniversalXPConnect privileges to use that.

Node.ELEMENT_NODE is part of the DOM, right? You shouldn't need to use XPConnect to access it, I think. Maybe that object doesn't have a ClassInfo. ClassInfo tells the security manager that the object should be fully scriptable without privileges.

That said, using UniversalXPConnect is just fine, no reason not to. It just probably shouldn't be a requirement in this case.

Yes, Node.ELEMENT_NODE is part of the DOM, in mozilla it maps to window.Components.interfaces.nsIDOMNode.ELEMENT_NODE.

Found the xbl permissions bug, adding dependency. The right fix should go there. I still hope for the right fix to exist, instead of having to whack class info for everything. (which may or may not be a good idea for some objects, is nsOutlinerBoxObject one of them?) Anyway, I never needed the trick for Node.ELEMENT_NODE on solaris, so that one still puzzles me. Axel

Adding classinfo to the class nsOutlinerBoxObject is not a bad idea (and should be done), but Axel's right, we shouldn't blindly add classinfo to every class w/o thinking about what we're doing...

If classes are part of the DOM, then why shouldn't they have a classInfo that advertises them as such? For this bug, should we go ahead and add classInfo to nsOutlinerBoxObject?

Other box objects already have classinfo, I see no reason not to add classinfo to this one. However, nsOutlinerBoxObject, inherits nsBoxObject, which already has classinfo (and nsOutlinerBoxObject::QI() does call into nsBoxObject::QI()), so why is that not enough?

Seems like that ought to work; I'm not sure what the problem is. We should look at it together.

I think the inherited DOM class info doesn't work because it needs things from the nsIOutlinerBoxObject interface, which nsBoxObject doesn't implement.

The inherited classinfo stuff should work, the helper used for the boxobject does allow for QI'ing the JS objects to any interface, even if it's not in the list of interfaces supported by the object. People use QI on boxobjects in JS to get between interfaces, so a missing interface in the boxobject's interface map shouldn't matter.

milestone 0.9.4

Selection needs class info also. nsIOutlinerSelection. Is that the bug?

This patch isn't good anymore, jst changed stuff while landing prototypes. Hyatt, nsIOutlinerSelection is already good, NS_DEFINE_CLASSINFO_DATA(OutlinerSelection, nsDOMGenericSH, DEFAULT_SCRIPTABLE_FLAGS) in mozilla/dom/src/base/nsClassInfo.cpp Axel

Moving to 0.9.5.

time marches on...retargeting to 0.9.6

I'll attach a patch that makes mozilla/layout/xul/base/src/outliner/outliner.xul a non-asserting test-app again. Is 'working from file/remotely' XUL1.0 relevant?

performance, footprint, feature work, and re-architecture bugs will be addressed in 0.9.8

Mozilla1.0

Moving Netscape owned 0.9.9 and 1.0 bugs that don't have an nsbeta1, nsbeta1+, topembed, topembed+, Mozilla0.9.9+ or Mozilla1.0+ keyword. Please send any questions or feedback about this to adt@netscape.com. You can search for "Moving bugs not scheduled for a project" to quickly delete this bugmail.

Futuring.

outliner is long-since dead. Could we re-evaluate this bug, please?