357352 - e4x/Namespace/regress-350442.js is too strict

Status: VERIFIED FIXED

(Core :: JavaScript Engine, defect)

Description

[David Caldwell]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.7) Gecko/20060909 Firefox/1.5.0.7

In the JavaScript Test Library, the regression test for Bug#350442 requires that the implementation choose "ns2" as the namespace prefix for the namespace "http://ns2"  A conforming implementation ought to be able to choose any namespace it likes.

Reproducible: Always




Two ways to fix this, one hard, one easy.  I'll attach a patch for the easy one.  The hard way would be to do more robust comparisons when evaluating these tests for passage, i.e., to use XML equality rather than string equality.  Of course then we could have more subtle regressions if the XML equality stuff breaks.

The quicker, dirtier solution is to specify the namespace prefix in the test, which is what I propose in my patch.

Comment 1

[David Caldwell]

Attachment: Patch to specify namespace prefix

A one-liner.

Comment 2

[Bob Clary [:bc] (inactive)]

no need to cc me on js bugs.

With this change, the test fails on trunk with:
BUGNUMBER: 350442

STATUS: toXMLString with namespace definitions
FAILED!: Section 1 of test -
FAILED!: Expected value:
FAILED!: <tag1 ns2:a1="a1 from ns2" xmlns="http://ns1" xmlns:ns2="http://ns2"/>
FAILED!: Actual value:
FAILED!: <tag1 ns2:a1="a1 from ns2" xmlns="http://ns1"/>
FAILED!: 

Igor?

Comment 3

[Jeff Walden [:Waldo]]

Attachment: Don't require a particular prefix be generated

I think this should do the trick, barring extreme and unusual spec violations by the implementation being tested.  David, does this look spec-compatible to you?

Comment 4

[Jeff Walden [:Waldo]]

(In reply to comment #2)
> With this change, the test fails on trunk with:
> BUGNUMBER: 350442
> 
> STATUS: toXMLString with namespace definitions
> FAILED!: Section 1 of test -
> FAILED!: Expected value:
> FAILED!: <tag1 ns2:a1="a1 from ns2" xmlns="http://ns1" xmlns:ns2="http://ns2"/>
> FAILED!: Actual value:
> FAILED!: <tag1 ns2:a1="a1 from ns2" xmlns="http://ns1"/>
> FAILED!: 

Hmm, that's a bug somewhere -- filed bug 357471 on it.

Comment 5

[David Caldwell]

Yes, I think the proposed patch catches most plausible cases, and most cases that would pass the test but be wrong (having a prefix defined to be the wrong namespace, etc.) are pretty implausible.  Sorry it took me so long to get back on this.

Comment 6

[Jeff Walden [:Waldo]]

Attachment: Same as previous, but don't be greedy when determining prefix

Don't worry about the delay; everyone's busy, and I still need to act on the wiki stuff you posted nearly a month ago.  :-\  Thanks for taking the time to look at it.

I noticed when looking at this again that the method used to get the prefix is greedy; this version changes that to be "non-greedy" so that the prefix extraction would work even if another prefixed namespace declaration were added (there's no actual effect on current execution):

var s = '<t xmlns:a="f" xmlns:b="g" b:f="7"/>';
/xmlns:(.+)="g"/.exec(s)[1] == 'a="f" xmlns:b'; // true
/xmlns:([^=]+)="g"/.exec(s)[1] == 'b'; // true

The change made is as above: "([^=]+)" instead of "(.+)".  I'll commit the fix in a second...

Comment 7

[Jeff Walden [:Waldo]]

Patch checked in on trunk.

Comment 8

[Bob Clary [:bc] (inactive)]

test passes 20061122 1.8.1.1/1.9