138850 - Permission denied in method on bindings with file extension ".xbl" in chrome://

Status: RESOLVED FIXED

(Core :: XBL, defect)

Description

[Eric Desbiens]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.9+) Gecko/20020416
BuildID:    2002041617

When a method is define in XBL and the methods access the DOM, the Javascript
console always display this error message :

Error : uncaught exception: Permission denied to call method
XULDocument.getAnonymousElementByAttribute

If the file is rename with .xml extension, everything works fine.

The permission is only denied in the methods, if access from the constructor, it
works.

Reproducible: Always
Steps to Reproduce:
1.Create a file with .xbl extension with a method accessing the dom
2.Call the method


Actual Results:  Following error is thrown :
Error : uncaught exception: Permission denied to call method
XULDocument.getAnonymousElementByAttribute

Expected Results:  The method should have permission to access the dom

Comment 1

[Brendan Eich [:brendan]]

Can this get fixed for 1.0, to make .xbl a viable option?  We already took some
pains to support that suffix, IIRC.

/be

Comment 2

[Håkan Waara]

This is a regression from bz's fix to bug 117839.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Really?  It was that fix which allowed .xbl files to start with, no?

Is there a testcase?  I can easily back out the patch from that and test...

Comment 4

[Brendan Eich [:brendan]]

hwaara: your wording is ambiguous.  I know you do not mean that bz's change
regressed things, resulting in this bug, but that's one interpretation of what
you wrote.  Maybe "this is a regression from the working state of things for the
.xbl suffix, achieved by bz's patch for bug ...." or something akin would be better.

bz, not to worry -- you didn't break anything.  But something broke (we think)
things so that .xbl is not equivalent to .xml for XML source file suffixing.

/be

Comment 5

[Hixie (not reading bugmail)]

(a) Why would you use the .xbl extension?
(b) I assume this is for content type sniffing, e.g. for file:// and chrome://?

Comment 6

[Eric Desbiens]

Attachment: Testcase using .xbl and .xml

testcase-error.xul use the xbl file that throw the error.
testcase-ok.xul use the xml file with exactly the same content as the xbl one
and does not throw any error.

Note : You need to access the files in a chrome:// location for the permission
denied exception to be thrown, if you use File->Open File... the error is not
there.

To answer Hixie question : 
(a) Why would you use the .xbl extension?
   For the same reason for using a .xul .rdf .svg extension. Easily recognize
the content of the file has xbl binding and not some arbitrary xml data.

(b) I assume this is for content type sniffing, e.g. for file:// and chrome://?

   Hmmm... don't know exactly what you mean, but see above note.

Comment 7

[Hixie (not reading bugmail)]

(a) fair enough
(b) ok, so this is for chrome:// only, not HTTP, which is what I was worried
about. (For HTTP we should not be using the extension at all, only the
Content-Type header.)

Comment 8

[Axel Hecht]

Attachment: testcase-error.xbl working at least from file://

Here is a modification of testcase-error.xbl which works for me, loading from
file://.
I didn't check this out for chrome://, I had some not-really reproducable
problems
with the original one, though.
I added some dumps, and both the constructor as the arrange method work
allright.

tested on today's CVS trunk, solaris

Comment 9

[Boris Zbarsky [:bzbarsky]]

Is this still an issue?

Comment 10

[Boris Zbarsky [:bzbarsky]]

This was fixed by bug 221490