User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:220.127.116.11) Gecko/20110319 Firefox/3.6.16
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:18.104.22.168) Gecko/20110319 Firefox/3.6.16
In Firefox 4 I am getting this error when running remote XUL pages:
Error: Permission denied for <https://www.arcamax.com> to call method BoxObject.QueryInterface.
It works in Firefox 3.6
I have this app on 4 different servers. All sub-domains of arcamax.com. 3 of them are test servers and one is a production server. Currently the JAR file on all 4 is identical. The same certificate was used to sign the JAR files on all servers. One domain works, and the others do not.
I have the Remote XUL manager installed and have white listed all the domains I use this with it. All the domains in question are sub-domains of arcamax.com. I have tried adding just arcamax.com or all 4 full domain names with the same results.
All add-ons are currently disabled including the Remote XUL Manager. Disabling the add-on does not appear to interfere with the white list that I set up.
It seems to consistently favor one of the servers. However if I load the JAR from one of the other servers and then 'Restart with all Add-ons disabled', it will come back up with that server working. However it will not reload that page. It is like the reload occurs before all the security checks are in place. That may be a separate bug.
Other developers here are seeing the same thing but just with a different server that always works.
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?
view.Tree.view = view;
The exception is thrown on the assignment. 'view' is my tree view object. 'view.Tree' is an XUL tree element.
Is there a way to get the filename and line number from a caught exception?
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);"
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:
There has been some discussion of this issue here:
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.
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
I have narrowed it down to:
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.