479839 - XBL loading problems in 3.1b2

Status: RESOLVED WONTFIX

(Core :: XBL, defect)

Description

[Moisés Campos]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.0.6) Gecko/2009011913 Firefox/3.0.6 (.NET CLR 3.5.30729)
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9.1b2) Gecko/20081201 Firefox/3.1b2 (.NET CLR 3.5.30729)

I have one extension that use CSS binding to load the XBL from one URL (not from chrome). In version 3.0 this is working fine. Testing the same code in 3.1b2 dosen't work. nothing on Error Console2. 


Code explanation: 

1. The extension opens a new window, like this: 
window.openDialog("chrome://cms/content/app/app.xul", ...); 

2. app.xul is something like this: 
-------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<?xml-stylesheet href="chrome://global/skin/global.css" type="text/css"?>
<?xml-stylesheet href="chrome://cms/content/cmselements.css" type="text/css"?>

<window id="cms"
        xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul"
        xmlns:html="http://www.w3.org/1999/xhtml"
		title="" 
		onload="startApp()"
		sizemode="normal"
        screenX="10" screenY="10"
        width="400" height="400"
        persist="screenX screenY sizemode"
		>
				
		<vbox id="windowContent" flex="1">
		</vbox>
</window> 
-------------------------------------------


3. startApp() definition: 

function starApp() {
	document.loadOverlay("http://teste.pt/a.xul", new loadApp());
} 

loadApp is a normal observer. 


4. XUL (remote file a.xul) 
-------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE window SYSTEM "chrome://cms/locale/app.dtd">

<overlay id="conteudo-overlay"
         xmlns="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul">
	<vbox id="windowContent">
	<vbox flex="1" style="-moz-binding:url('http://test.pt/bindings/cmsSelectMedida.xml#cmsSelectMedida')"/>	
</overlay>
-------------------------------------------


The Binding can be anything. Example: 
-------------------------------------------
<?xml version="1.0" encoding="UTF-8"?>
<bindings id="cmsXBLSelectMedida" 
	xmlns="http://www.mozilla.org/xbl" 
	xmlns:xul="http://www.mozilla.org/keymaster/gatekeeper/there.is.only.xul" 
	xmlns:xbl="http://www.mozilla.org/xbl">
	
  <binding id="cmsSelectMedida" extends="chrome://global/content/bindings/general.xml#basecontrol">  
  	    <content>
  	    	<xul:textbox/>
  	    	<xul:textbox/>
  	    </content>
	</binding>
</bindings>  	   
-------------------------------------------

Reproducible: Always

Steps to Reproduce:
1. From extension menu, hit the option that open the dialog
2. The XBL buttons dosent appear.
3.
Actual Results:  
Nothing appears. 

Expected Results:  
In version 3.0 the buttons appears.

Comment 1

[Dave Garrett]

Please test in a more recent build. Beta 2 is old.
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla-1.9.1/

Comment 2

[Moisés Campos]

Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090223 Shiretoko/3.1b3pre (.NET CLR 3.5.30729)

The same problem persist.

Comment 3

[Dave Garrett]

I suggest you attach a simple test extension here so others can easily test using what you've mentioned above.

Comment 4

[Boris Zbarsky [:bzbarsky]]

Does this only fail for a binding that's not same-origin with the document in question (as above)?

Comment 5

[Moisés Campos]

Yes, that's correct. The extension that we are deploying needs to load some bindings that are not part of the chrome itself. The main goal is to avoid putting everything on the extension. 

So part of the XUL is on the extension, and some overlays and bindings are loaded from a remote site. 

I represent one company that is trying to use Gecko to build a Content Managment System. It is really important that we can get this working. 

To get the perfect view, perharps we could give the URL, login and password to our system to get the point. But i dont want to put this information in the public area of bugzila. Can i send one direct email ?

Comment 6

[Boris Zbarsky [:bzbarsky]]

> So part of the XUL is on the extension, and some overlays and bindings are
> loaded from a remote site. 

Hmm.  That should sort of work as long as the loading principal is system 
(which yours should be).  You're introducing a security bug, but I'm not going to worry about that for right now; I assume your final deployed system is served over SSL, say.

You can mail me whatever credentials are needed with steps to reproduce.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Sorry for the lag here; Moisés did mail me the info I requested on March 5, but it took me a while to get to it because the XUL file uses a menubar, as far as I can tell, which doesn't work on Mac (because mac menus are special).

On Linux, I did reproduce the problem.  When the failure occurs there is a JS error:

  Javascript error: chrome://[redacted] -> http://[redacted], line 28:
  medida.removeAllItems is not a function.

That JS filename made me realize that we did in fact disable non-chrome XBL loading from chrome, or rather from chrome packages that get XPCNativeWrapper automation.  And we did in fact make that change first in 1.9.1b2, in bug 425153.

I don't think we want to change this behavior; certainly not to allow loads from http: (which are a security hole in this case, as I said in comment 6, because a man-in-the-middle attack will execute with chrome privileges).

Moisés, you have several options:

1)  Turn off xpcnativewrapper automation for your extension package (or just
    for the package the XUL file that needs to load non-chrome things lives
    in; ideally you'd disable it for as small a number of files as possible)
    and in the relevant files be _very_ careful how you touch untrusted
    objects.
2)  Link to chrome:// XBL bindings, but have those chrome URIs resolve to https
    URIs.  This is suboptimal in that it will cause sync loads of https URIs,
    but that might be OK in this case.
3)  Put all the bindings in the chrome package.
4)  Dynamically create chrome packages with he relevant bindings as needed.

There might be other more complicated things, but these are the obvious ones.

I suspect this bug as filed is wontfix.  jst, sicking, opinions?

Comment 8

[Philip Chee]

> 1)  Turn off xpcnativewrapper automation for your extension package (or just
Is there any documentation on how to do this? Thanks.

Comment 9

[Boris Zbarsky [:bzbarsky]]

https://developer.mozilla.org/en/Chrome_Registration#xpcnativewrappers

It's linked from the article on XPCNativeWrapper on devmo, for what it's worth.

Of course if you do this you need to be VERY careful about touching content DOMs.

Comment 10

[Philip Chee]

Thanks Boris. I know about this. I just didn't realize that "xpcnativewrapper automation" was the same thing and searching mdc for this phrase didn't turn up anything obvious. Should I flag this bug dev-doc-needed?

Comment 11

[Boris Zbarsky [:bzbarsky]]

Probably a good idea.

Comment 12

[Eric Shepherd [:sheppy]]

Added the term "xpcnativewrapper automation" to the article that covers this, to improve search results.