330572 - E4X: using default xml namespace assignment inside of function has no effect

Status: RESOLVED FIXED

(Core :: JavaScript Engine, defect)

Description

[Martin Honnen]

Someone on Usenet run into trouble with Mozilla and E4X when using the default xml namespace assignment.

I have made a test case and indeed I think Spidermonkey is not working correctly with that assignment executed in function scope. The created default namespace does not seem to be in scope when gods.god is evaluated.

If I load
<http://home.arcor.de/martin.honnen/mozillaBugs/e4x/defaultNamespace1.js>
in the Spidermonkey shell (after pulling latest changes via CVS and doing a clean build) the result is

js> load('mozillaBugs/e4x/defaultNamespace1.js')
gods.god.length: 0
gods.god.length: 0

while Rhino (1.6 R2) shows the correct result

js> load('mozillaBugs/e4x/defaultNamespace1.js')
gods.god.length: 0
gods.god.length: 1

So with Spidermonkey the result of gods.god.length() is the same before and after the assignment
  default xml namespace = "http://example.com/2006/gods";
which is a bug, after that assigment the length should be 1.

If I do not put the whole code inside of a function but rather have it in global scope as in 
<http://home.arcor.de/martin.honnen/mozillaBugs/e4x/defaultNamespace2.js>
then the result with Spidermonkey is correct:

js> load('mozillaBugs/e4x/defaultNamespace2.js')
gods.god.length: 0
gods.god.length: 1

HTML test case embedding that script is at
<http://home.arcor.de/martin.honnen/mozillaBugs/e4x/defaultNamespace2.html>, works fine with both Firefox 1.5.0.1 as well as a night trunk Firefox build.

Comment 1

[nanto_vi (TOYAMA Nao)]

This bug doesn't occur if the function has operations that change a scope chain.  For example,

function f() {
  default xml namespace = "foo";
  var a = <a><b/></a>;
  return a.b;
}

incorrectly returns an empty XMLList but

function f() {
  default xml namespace = "foo";
  var a = <a><b/></a>;
  return a.b;
  function g() { return a; }
}

returns <b xmlns="foo"/>.  And |function g() { return a; }| can be other operations such as |with ({});| or |<></>.(some.expr);|.

So we can remove a potentially needless statement in Calendar (*) when this bug is fixed.
* http://lxr.mozilla.org/seamonkey/source/calendar/providers/gdata/components/calGoogleCalendar.js#668

Comment 2

[Robert]

This still isn't fixed in Firefox 3.0.3. It took me about three hours to recognize that I'm not misunderstanding the documentations, but that "default xml namespace" simply doesn't work under certain circumstances. My work-around is very similar, I added the following dummy command at the end of my function:

/* workaround */0==function(){dummy()};/* workaround */

Anyway, I hope that this gets fixed sometime... although this problem has appearently been known for two and a half year now.

Comment 3

[Brendan Eich [:brendan]]

This was fixed by the patch for bug 512389.

/be