Incorrect E4X filter scope for functions

UNCONFIRMED
Unassigned

Status

UNCONFIRMED
9 years ago
6 years ago

People

(Reporter: jbeard4, Unassigned)

Tracking

Details

Attachments

(1 attachment)

(Reporter)

Description

9 years ago
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.
(Reporter)

Comment 1

9 years ago
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.
(Reporter)

Comment 2

9 years ago
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

9 years ago
Created attachment 432448 [details] [diff] [review]
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?
(Reporter)

Comment 4

9 years ago
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.
e4x support has been removed (bug 788293).
Status: UNCONFIRMED → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WONTFIX

Comment 6

6 years ago
Again, what E4X removal from Spidermonkey to do with Rhino?
Sorry, I didn't see that this was about Rhino.
Status: RESOLVED → UNCONFIRMED
Resolution: WONTFIX → ---
You need to log in before you can comment on or make changes to this bug.