551854 - Incorrect E4X filter scope for functions

Status: RESOLVED INACTIVE

(Rhino Graveyard :: E4X, defect)

Description

[Jake]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US) AppleWebKit/532.5 (KHTML, like Gecko) Chrome/4.1.249.1021 Safari/532.5
Build Identifier: 1_7R2

From ECMA-375, 2nd edition, section 11.2.4, it seems that given

xml = <xml><e id="1"/><e id="2"/></xml>;

the following code

xml.*.(@id == "1")

(which returns the <e id="1"/> element) could also be written as

xml.*.(attribute("id") == "1")

I.e., not only the node's properties but also its methods should be available to the filters. However, this is not the case in Rhino. It does work in Flex/ActionScript, but not in Rhino or SpiderMonkey.

Reproducible: Always

Steps to Reproduce:
1. Start Rhino
2. xml = <test></test>
3. xml.(descendants())
Actual Results:  
js: "<stdin>", line 3: uncaught JavaScript runtime exception: ReferenceError: "descendants
" is not defined.
        at <stdin>:3

Expected Results:  
Returns:
<test></test>

Patch proposed: http://groups.google.com/group/mozilla.dev.tech.js-engine.rhino/browse_thread/thread/f85e89c4b8e8011d#

Same behaviour in Spidermonkey 1.8.0-rc1.

Comment 1

[Jake]

I spent a few hours tonight debugging this in Eclipse, and it appears as though the issue is that methods like "descendants" do not show up as actual methods, and thus slots or properties, on the XML objects. Rather, XMLObjectImpl.execIdCall is called, which switches these methods and delegates them to methods on the native Java object. 

So, when the filter is called with, e.g. descendants, the scoping appears to be handled properly, which is to say that the object lookups are delegated to the prototype, which is the context XML node. So, you end up in hasXMLProperty, with xmlName argument set as "descendants". The lookup under getPropertyList fails, as it should, but then the lookup under getMethod(xmlName.localName()) fails, which it should not. The getMethod lookup fails because it delegates all the way up to ScriptableObject.getSlot, which fails to find a slot named "descendants".

It seems the solution would be to expose these built-in XML methods as actual slots on the object, but I'm new to Rhino, and I'm not yet clear on what would be the best way to go about doing that.

Comment 2

[Jake]

Also, the patch I linked to in the summary does not work. Delegation does not appear to be the problem, which is what that patch aimed to solve.

Comment 3

[Martin Blom]

Attachment: Another approach

OK, my first attempt was clearly wrong. Here's another try.

Basically, if nameOfFunction() looks for a method and it's ''with'' an XML object, we use the same semantics as ECMA-357 11.2.2.1 CallMethod to look up a suitable method.

What do you think?

Comment 4

[Jake]

Martin,

I've done some tests, and it's been working well for me. I think I'm going to try to use it in the project which I had originally intended it, and so I'll be able to report any bugs I find that might be caused by this patch.

Great work, I hope it gets accepted upstream.

Comment 5

[Nicholas Nethercote [inactive]]

e4x support has been removed (bug 788293).

Comment 6

[Martin Blom]

Again, what E4X removal from Spidermonkey to do with Rhino?

Comment 7

[Nicholas Nethercote [inactive]]

Sorry, I didn't see that this was about Rhino.

Comment 8

[Sylvestre Ledru [:Sylvestre]]

Closing. Bug management is now done here:
https://github.com/mozilla/rhino