440275 - Permission denied to call method Element.getAttribute

Status: VERIFIED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[John J. Barton]

The subject error message comes out, no one knows why.

From
http://groups.google.com/group/firebug/browse_thread/thread/fa19b80dfbfb566c

this code breaks on FF3 when firebug is on.
works on FF3 with firebug off.
works on FF2 with firebug on or off.

needs two files.

1) test.html: on body load  call test();
2) test.xml:  some little xml doc to be  loaded.

=== in test.html ===
var doc;
function test(){
        doc = document.implementation.createDocument("", "", null);
        doc.onload = function(e){
                alert(doc.firstChild.getAttribute("id")); //<--HERE
        };
        doc.load("test.xml");

}

=== and in test.xml ===
<thing id="theid">
 <foo/>
</thing>

Comment 1

[John J. Barton]

See also Bug 385676, Bug 427052 

Comment 2

[John J. Barton]

Attachment: bug440275.html

Comment 3

[John J. Barton]

Attachment: bug440275.xml

Should use a data url if I knew how...

Comment 4

[Doug Domeny]

I've also seen the same error with firstChild.

Comment 5

[Mike Shaver (:shaver emeritus)]

I don't really know what component this belongs in, but DOM seems like a decent start.  Could some of the principal-knowing sorts point us in the right direction?

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

As far as I can tell, the base cause for the error message here is that nobody calls SetScriptGlobalObject for documents that are created via createDocument (as opposed to those that are created for actual viewing). We do call SetScriptHandlingObject, but that doesn't set mScopeObject. This means that it's possible for us to have multiple XPCWrappedNatives for the same document. That's bad, right there, but it goes one further: because we cache the document JSObject pointer in the document, we end up with a pigeon hole: the 2nd document reset's the document's idea of what its JSObject is. Therefore, when we're wrapping the firstChild in a wn, we hit this code:

  if (native_parent == doc && (*parentObj = doc->GetJSObject())) {

and wrap the first child in Firebug's (chrome!) scope. As a hack, I set mScopeObject in nsDocument::SetScriptHandlingObject and it fixed this bug (no more permission denied errors) but I'm not sure if it's correct.

Comment 7

[Boris Zbarsky [:bzbarsky]]

That's the same issue we had with XMLHttpRequest documents in terms of principals...  I still think the "right" solution there is to have an XPConnect scope associated with each document, not just with some documents.

jst would know about the mScopeObject thing as a quick-fix...

Comment 8

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: Possible hack or fix

Johnny, what do you think?

Comment 9

[John J. Barton]

Another test case on public URL:
http://www.w3schools.com/DOM/tryit.asp?filename=try_dom_attributes
click the button, example fails because of exception.

Comment 10

[Johnny Stenback (:jst)]

Comment on attachment 326905 [details] [diff] [review]
Possible hack or fix

Looks like this should work, and does the right thing AFAICT. r+sr=jst

Blake, please add something like this to your .hgrc:

[defaults]
diff = -p

to make your patches easier to read :)

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

Pushed as changeset 41acba08c036.

Comment 12

[Boris Zbarsky [:bzbarsky]]

Should be able to write a browser/chrome test for this, no?

Comment 13

[Mike Shaver (:shaver emeritus)]

mrbkap: what are your thoughs on a test for this?

mrbkap/jst/bz/etc.: is this 1.9.0.x-fodder?  Would be great to get rid of these spurious errors at long last!

Comment 14

[Blake Kaplan (:mrbkap) (inactive)]

I took a stab at this before, but ran into some trouble creating a content frame. I'll try again soon.

Comment 15

[Mike Shaver (:shaver emeritus)]

This fixes the test case linked from comment 9, would like to get it to 1.9.0.x to help Firebug there. mrbkap: when you have a test case, can you nom an appropriate patch for branch?

Comment 16

[John J. Barton]

When I try the test case from comment 9 on 
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9) Gecko/2008052906 Firefox/3.0
I get:
Permission denied to get property Element.attributes
http://www.w3schools.com/DOM/tryit_view.asp?filename=try_dom_attributes
Line 11

I'm confused as to whether this is:
  1) correct answer, user web page is wrong
  2) wrong answer, my version of Firefox does not have "this fix"
  3) wrong answer, fix failed.
  

Comment 17

[Mike Shaver (:shaver emeritus)]

>   2) wrong answer, my version of Firefox does not have "this fix"

The fix was committed to the nightly trunk, and hasn't been backported to the 3.0.x series yet (that's why I asked mrbkap to nominate a patch when he had a test suite case for it).

Comment 18

[Blake Kaplan (:mrbkap) (inactive)]

I'm going to have to punt on this one -- I can't figure out how to write the mochitest :-/.

Comment 19

[John J. Barton]

Rob? We probably need to track down what in Firebug sets up the problem, I can help with that if you understand mochitest.

Comment 20

[Blake Kaplan (:mrbkap) (inactive)]

As I recall, there is a content handler that is run after the document.load document is loaded. Firebug touches the document at that point, exposing the bug. I'll be able to provide more detail in a few days if needed.

Comment 21

[Blake Kaplan (:mrbkap) (inactive)]

Comment on attachment 326905 [details] [diff] [review]
Possible hack or fix

Drivers: see comments earlier in this bug about the possibility of a mochitest.

Comment 22

[John J. Barton]

I tested the set of Firebug bug reports that seem to be related this fix and reported the results on bug 434522. Backporting this would be great for Firebug users.

Comment 23

[Samuel Sidler (old account; do not CC)]

Comment on attachment 326905 [details] [diff] [review]
Possible hack or fix

Approved for 1.9.0.2. Please land in CVS. a=ss

Comment 24

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked into the 1.9 branch.

Comment 26

[John J. Barton]

Pushing on this.

Comment 27

[Mike Shaver (:shaver emeritus)]

This already landed in the tree for 3.0.2 (comment 24, and the fixed1.9.0.2 keyword).  Probably worth testing with a 3.0.2pre nightly if you haven't already, though.

Comment 28

[John J. Barton]

A user has verified this fix in 3.0.2.