263934 - XMLList assign produces bogus result

Status: RESOLVED FIXED

(Rhino Graveyard :: E4X, defect)

Description

[Igor Bukanov]

-------- Original Message --------
Subject: Found a few E4X bugs
Date: Fri, 30 Jul 2004 16:47:40 -0700
From: John Schneider <[e-mail]>
Reply-To: <[e-mail]>
Organization: AgileDelta, Inc.

Description: Replacing a list item with a new list that contains that item
causes incorrect result.

Test case:

	var x = <x>
			<b>two</b>
			<b>three</b>
		  </x>;

	// insert <a> element in from of first <b> element
	x.b[0] = <a>one</a> + x.b[0];

	print(x);

Expected:

	<x>
		<a>one</a>
		<b>two</b>
		<b>three</b>
	</x>

Actual:

	<x>
		<a>one</a>
		<a>one</a>
		<b>three</b>
	</x>

Comment 1

[Igor Bukanov]

Wrong bug to resolve

Comment 2

[Hannes Wallnoefer]

I found a similar problem when appending elements using the += operator. The
problem only appears if there are space characters between tags in the existing
list and XML.ignoreWhitespace is set to false. Here's how to reproduce it in
Rhino shell:

js> XML.ignoreWhitespace = false;
false
js> var xml = <a> <b/><b/></a>;
js> xml.b += <c/>;
<b/>
<b/>
<c/>
js> print(xml);
<a>
  <b/>
</a>
js>

The expected result from print(xml) would be 

<a>
  <b/>
  <b/>
  <c/>
</a>

Note that if I leave away the space char in the original XML literal, or don't
set XML.ignoreWhitespace to false, the result is as expected. If I add more
spaces, I get other bogus results. 

Should I file a new bug for this? Are there any insights on the original bug,
such as where to look, and if this is a Rhino or a XMLBeans bug?

Comment 3

[Igor Bukanov]

Marking as fixed: new issues should be reported as bugs

Comment 4

[Igor Bukanov]

I "fixed" the wrong bug.

Comment 5

[Igor Bukanov]

Reassigning to [e-mail] pending resolution of bug 288433

Comment 6

[David Caldwell]

This issue is fixed in the coming non-XMLBeans implementation of E4X, or at least the first issue is.  The test in comment #2 gives output other than that suggested, but I'm not sure which is right.  The output given is:

<a>

  <b/>
  <b/>
  <c/>
</a>

I'd have to carefully go back to the pretty-printing part of the spec to see whether the extra newline is appropriate given the presence of a non-empty text node in there.

Comment 7

[David Caldwell]

My reading of ECMA357 2nd ed. 10.2.1 is that the output in comment 6 is correct, thus I am closing this bug as fixed (if XMLBeans is not present, of course; see bug 355677).

Comment 8

[Norris Boyd]

Adding target milestone of 1.6R6 based on the date this bug was resolved FIXED.