Last Comment Bug 646840 - Remote XUL Fails on some servers
: Remote XUL Fails on some servers
Product: Core
Classification: Components
Component: General (show other bugs)
: 2.0 Branch
: x86 Windows 7
: -- normal (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
Depends on: CVE-2011-2993
  Show dependency treegraph
Reported: 2011-03-31 08:14 PDT by Bryan White
Modified: 2011-07-01 20:15 PDT (History)
5 users (show)
See Also:
Crash Signature:
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Description Bryan White 2011-03-31 08:14:42 PDT
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110319 Firefox/3.6.16
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20110319 Firefox/3.6.16

In Firefox 4 I am getting this error when running remote XUL pages:
Error: Permission denied for <> to call method BoxObject.QueryInterface.

It works in Firefox 3.6

I have this app on 4 different servers. All sub-domains of 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 I have tried adding just 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.

The javascript in the jar file has only a single call to QueryInterface and it is not in a function that would be invoked at startup. It does define QueryInteface functions in connection with defining custom tree view objects.

Other developers here are seeing the same thing but just with a different server that always works.

Reproducible: Always
Comment 1 Boris Zbarsky [:bz] 2011-04-01 09:44:08 PDT
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?
Comment 2 Bryan White 2011-04-01 11:24:16 PDT
The error is occuring as a javascript exception.  It occurs in in this code:
  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?
Comment 3 Boris Zbarsky [:bz] 2011-04-01 11:44:11 PDT
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?
Comment 4 Bryan White 2011-04-12 10:24:18 PDT
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.
Comment 5 Bryan White 2011-06-21 10:00:44 PDT
FYI:  This is still not working in FireFox 5.0
Comment 6 Bryan White 2011-07-01 07:19:28 PDT
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?
Comment 7 Boris Zbarsky [:bz] 2011-07-01 07:59:01 PDT
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.
Comment 8 Bryan White 2011-07-01 08:44:24 PDT
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.
Comment 11 Boris Zbarsky [:bz] 2011-07-01 20:15:47 PDT

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.

Note You need to log in before you can comment on or make changes to this bug.