E4X sucks, in that it hides methods and always wraps property values in an
XMLList. The __noSuchMethod__ you define is not working because while it is
well-defined in the function:: namespace, it is not invoked by that qualified
name. This will be ugly to fix -- initial plan is to hack in an OBJECT_IS_XML
test and qualify for that ugly case.
/be

Comment on attachment 199523[details][diff][review]
proposed fix
Oops. Another fix in the next patch to this one: set vp[1] to root thisp on
successful return from getMethod in js_Invoke's __noSuchMethod__ block.
/be

Fixed on the trunk. Would like to fix for 1.8, or something that releases soon
enough off it into the Firefox 1.5+ patch-stream. Thinking about going for rc1
approval. Nominating on that basis.
The bug is that E4X, new in 1.8/fx1.5, can't be used with the pre-existing hook
for handling a call to an undefined method on an object, __noSuchMethod__. The
combination is powerful, and the lack can't be worked around at all. The patch
is totally confined to __noSuchMethod__ and E4X (function::foo property get and
set) code paths, so it's not going to break anything else in JS.
/be

This seems to cause "(function a() {this.b();}).toSource();" to return
"(function a() {this.function::b();})" (was "(function a() {this.b();})") if
entered in the JavaScript Console, was this intended?

Comment on attachment 199978[details][diff][review]
overload a srcnote to distinguish explicit function::
I wonder if the future archaeologists will revere the decompiler as the
Platonic ideal of Internet-era Baroque.
sr=shaver

Created attachment 200301[details][diff][review]
branch roll-up patch
To recap: SpiderMonkey supports __noSuchMethod__ as a "default method handler",
for calling obj.foo() where foo is not defined. E4X, per spec, hids methods in
what is effectively an unnamed namespace in the XML.prototype object. Our E4X
implementation allows methods to be defined in an explicit function::-qualified
namespace, both to access the E4X prototype methods, and to shadow them in any
XML object that delegates to that prototype.
This patch fixes bugs in the interaction of the two features. It affects code
paths peculiar to those features, and a common set of paths involving "method"
property access. It tests well, and the changes to common code paths are small
enough to inspect. Without the fix, there is no workaround, either for using
__noSuchMethod__ with E4X (something AJAX developers want), or for overriding
methods with function::-qualified property assignments.
The lack of workarounds motivates this request to get fixed in 1.8. The major
trunk patch landed five days ago. The followup fix is for a decompiler change
that is not backward compatible, and is verbose (always emitting function::,
even when it wasn't used, for method calls). That's in too, and it tests as
fixed.
The risks at this point are minimal: something else wrong with the decompiler's
output that we don't test for and haven't noticed.
/be