The QueryInterface call in question is presumably in some XBL binding attached to one of the XUL elements you're using. Is there no filename/linenumber reported for that error?
Hmm. So in that situation the setter for "view" from tree.xml would be running and calling QueryInterface when it does this.treeBoxObject : 88 <property name="treeBoxObject" 89 onget="return this.boxObject.QueryInterface(Components.interfaces.nsITreeBoxObject);" 90 readonly="true"/> That code is of course compiled with the page's principal and with no special privileges... but we should be finding that enablePrivilege on the stack, no? Blake?
Here is an additional data point. I created a simple test jar file that has an xul tree and binds a view to it. Oddly am am seeing that if I load this simple app first in a session, the full blown app works but if I load the full blown app first both it and the simple app will fail in that session. My simple test jar file is here: jar:https://www.arcamax.com/remotexul.jar!/remotexul.xul There has been some discussion of this issue here: https://github.com/jvillalobos/Remote-XUL-Manager/issues/2 When I get some time I want to start stripping things out of the full app and try to narrow down what is causing the problem.
FYI: This is still not working in FireFox 5.0
I tried compiling from source in the hope I might be able to debug the problem. Lo an behold the problem did not occur. I did notice that none of my add ons were running. So I tried installing FF5 and disabling all my addons. That still failed. However I then installed nightly from today (July 1) and it seems to be working. I see these possibilities: 1) The problem has been fixed 2) There is something different about the nightly builds that causes it to work. 3) The fact that nightly does not load any addons is causing things to work some how. (I doubt the because disabling all addons in FF4 and FF5 did not fix the problem). If the problem has been fixed, will the fix be part of the next security release or will it wait for FF6?
Bryan, at the moment FF6 is the next planned security release (on August 16). There are no plans for intermediate releases unless a critical compatibility or security issue is discovered, and then there would be a special release with just that one fix. It's entirely possible that this issue was fixed by the changes in bug 657267 (which is in fact fixed in Firefox 6). That bug landed on mozilla-central on 2011-05-20, probably after that day's nightly was compiled, so we could double-check that by testing nightlies from that day and May 21.
I Tried the May 20 but ran into problems. Only debug builds were listed and when I ran it I got some sort of 'Side by Side' error. It said to look in the event log. There I found: Activation context generation failed for "C:\Program Files (x86)\Nightly\firefox.exe". Dependent Assembly Microsoft.VC80.DebugCRT,processorArchitecture="x86",publicKeyToken="1fc8b3b9a1e18e3b",type="win32",version="8.0.50727.762" could not be found. Please use sxstrace.exe for detailed diagnosis. I verified that the June 1 version works. Anyway at this point I am willing to wait for FF6 to come out.
OK. For what it's worth, an opt Win32 May 20 nightly is at ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011/05/2011-05-20-03-mozilla-central/firefox-6.0a1.en-US.win32.zip and May 21 is at ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011/05/2011-05-21-03-mozilla-central/firefox-6.0a1.en-US.win32.zip
Thanks! Yeah, that corresponds to bug 657267 landing. I got the date wrong in comment 7; it landed on TM on the 20th and merged to m-c on the 23rd. Looks like this is fixed.