25565 - XBL domain security bug (is it XBL or the chrome URL?)

Status: RESOLVED FIXED

(Core :: XBL, defect, P3)

Description

[Sjoerd Visscher]

If I use this code:

  <binding name="menubutton">
    <content excludes="template,observes,menupopup">
      <xul:titledbutton type="commandbutton" inherits="observes"
crop="right" allowevents="true" />
      <xul:titledbutton type="menubutton" inherits="observes" />
    </content>
    <handlers>
      <handler type="mouseover"
value="this.attributes.getNamedItem('hovering').value='true'" />
    </handlers>
  </binding>

then when I do a mouseover I get this error:

JavaScript Error: access disallowed from scripts at [Codebase
resource:///chrome/xulBindings.xml#] to documents at another domain
JavaScript Error: uncaught exception: [Exception... "Security error"  code:
"1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)"  location:
"<unknown>"]

IE has also security bugs, it sees different local directories (using
file://) as different domains.
Does Mozilla have the same problem?

Comment 1

[David Hyatt]

Hmmm.  This looks like a bug to me.  I'm taking the event handler in the XBL 
file and rebinding it to a node in another document.  I would think that once 
the handler was rebound, that it would no longer think it resided in the 
original document.

This must be a bug in BindCompiledEventHandler, right?  Brendan or Norris?

Comment 2

[Chris Waterson]

I believe that it is the case that an event handler is -compiled- using a
specific security principal; e.g., JS_CompileUCScriptForPrincipals(). So, the
access privileges of a script are determined at compile time, not bind time.

Comment 3

[Norris Boyd]

Yes, waterson is correct that the principal of a JavaScript function is saved at
compile time.

Where is the code loaded from? Is is chrome: or some other type of URI?

Comment 4

[David Hyatt]

Hmmm.  That's a shame.  I could modify my code to always compile over and over 
again, but I'd like to be able to save the compiled handler and rebind it to 
documents that could come from different domains.

Comment 5

[Chris Waterson]

can you get a hold of the XUL prototype document and compile using the 
protodoc's script object? see, for example, the code in 
nsXULElement::CompileEventHandler().

Comment 6

[Sjoerd Visscher]

It seems to work already in todays build???

Comment 7

[David Hyatt]

I wouldn't expect it to work.  There is a bug with the principals not being 
rebound.

Comment 8

[David Hyatt]

Fixed.

Comment 9

[Paul MacQuiddy]

please ignore, massive spam giving [e-mail] backlog of XPToolkits
resolved fixed bugs to verify