290660 - Exception when calling custom getter on Element objects in javascript

Status: RESOLVED DUPLICATE of bug 290777

(Core :: JavaScript Engine, defect)

Description

[Jeff Evans]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.7) Gecko/20050414 Firefox/1.0.3

In Firefox 1.0.2, one could write:
Element.prototype.__defineGetter__("xml", function () {
     return (new XMLSerializer()).serializeToString(this);
  });

Then, with an Element object, one could extract the xml by writing element.xml.
 In 1.0.3, when "element.xml" is evaluated, a error is thrown in the
"serializeToString(this)" call.  Using venkman, at that point, "this" is set to
an XPComponent, instead of an Element, and craziness happens under the hood. 
The specific error returned is:
[Exception... "Illegal operation on WrappedNative prototype object" nsresult:
"0x8057000c (NS_ERROR_XPC_BAD_OP_ON_WN_PROTO)" location: "JS frame :: blah blah
:: anonymous :: line blah " data: no]

Since 1.0.3 is so new, this has only been reported a few times, and I only found
one other bug that is similar (290659).  That applies to the Event object.  My
guess is this change is related to (290200) the security change made to prevent
scripts from changing intrinsic object getters and setters.  However, in this
case, I am adding a new getter, so I do not see this as a security vulnerability.  

The workaround is to create a helper function that takes an Element and calls
the serialize operation on it, but this requires editing all usages of the
getter, and also requires developers to check for IE when the function is
called, instead of using the getter to transparently support IE and mozilla.

I know that there are several projects (www.bwindows.net,
http://sarissa.sourceforge.net/, webfx.eae.net)that rely on the ability to add
getters and setters to built in objects like Element, etc, so if this ability is
not restored, it will greatly inconvenience the developers of those projects and
in some cases make their goals impossible.

An interesting thing to note is that I am able to add a "xml" getter to
Document, but not Element.  It is true that in 1.0.2 and before, I was able to
add an "xml" getter to both objects.

Reproducible: Always

Steps to Reproduce:
1. add getter to Element which calls serializeToString on the Element
2. call getter on an Element

Actual Results:  
jscript error thrown

Expected Results:  
returned the xml representation of the Element

I've prepared a test case which I'll attach next.

Comment 1

[Jeff Evans]

Attachment: demonstrates that Document xml getter works while Element xml getter doesn't work

load this page in firefox 1.0.3.  Click "Do Document Test".  A new XMLDocument
will be created and initialized with some xml.	then, the xml getter will be
called on the document and the result displayed in an alert.  There will not be
any errors in the JS console.  Next, click "Do Element Test".  Again, a new
XMLDocument object will be created and initailized, and then the xml getter
will be called on the documentElement of the XMLDocument.  Inside the getter,
serializeToString(this) will throw a JS exception, and the exception will show
up in the JS console.

Both tests will succeed in Firefox 1.0.2 and earlier.

Comment 2

[Jeff Evans]

I've figured out a workaround that doesn't require any heavy code changes. 
Instead of defining an xml getter for Document and Element, define it for Node.
 For Example:
if(typeof(Node) != 'undefined' && typeof(Node.prototype) != 'undefined'){
  Node.prototype.__defineGetter__("xml", function () {
     return (new XMLSerializer()).serializeToString(this);
  });
}

This works in 1.0.3 on Document and Element objects.  I would close this bug,
but I don't want other developers to have to go through the pain of figuring
this out.  What is the best way to announce this this workaround, if we cannot
restore the old behavior?

Comment 3

[:Gavin Sharp [email: [e-mail]]]

*** This bug has been marked as a duplicate of 290777 ***