Closed Bug 496316 Opened 11 years ago Closed 11 years ago

E4X: Namespace variable resolution fails ("xmlns is undefined") if defined in function context

Categories

(Core :: JavaScript Engine, defect, P2)

1.9.1 Branch
defect

Tracking

()

RESOLVED FIXED
mozilla1.9.1

People

(Reporter: zer0.kaos, Assigned: brendan)

References

Details

(Keywords: regression, Whiteboard: fixed-in-tracemonkey)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_6; en-us) AppleWebKit/528.16 (KHTML, like Gecko) Version/4.0 Safari/528.16
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1pre) Gecko/20090602 Shiretoko/3.5pre

In the new XULRunner build seems that E4X doesn't set correctly the xmlns attribute.

If we try to set "lang" attribute on xmlns, will be raised an ReferenceError ('xmlns is not defined") if this code is executed into a function.

This error is reproducible in Firefox (last build), both of Windows and OS X. Executing this line on Error Console:

 (function() {var xmlns = new Namespace("xml", "http://www.w3.org/XML/1998/namespace"); var xml = <data />; xml.@xmlns::lang = "en-US"; alert(xml.toXMLString());})()

will raise an error, meanwhile:

 var xmlns = new Namespace("xml", "http://www.w3.org/XML/1998/namespace"); var xml = <data />; xml.@xmlns::lang = "en-US"; alert(xml.toXMLString());

will be fine.

Reproducible: Always

Steps to Reproduce:
1. Open Error Console on Firefox
2. Evaluate: (function() {var xmlns = new Namespace("xml", "http://www.w3.org/XML/1998/namespace"); var xml = <data />; xml.@xmlns::lang = "en-US"; alert(xml.toXMLString());})()
3. The ReferenceError "xmlns is not defined" will be raised.
Actual Results:  
a ReferenceError that said xmlns is not defined

Expected Results:  
no throwing error, xmlns should be defined and lang attribute set as well; at the end, the alert() should be displayed the correct XML code with namespace and lang.
The short version of the above:

|xml.@xmlns::foo = "bar"| fails if xmlns was declared inside a function rather than globally. This regressed on 1.9.1 branch between 20090417 and 20090418.

Tweaking summary and confirming.
Severity: normal → critical
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: regression
Summary: xmlns is not set by E4X if the code is running in a function context (is undefined) → E4X: Namespace variable resolution fails ("xmlns is undefined") if defined in function context
Version: unspecified → 1.9.1 Branch
Blocks: tomtom
The regression range is 37d1bb0c86b5 to 7b39d6b3b56d. I ruled out bug 481514 and bug 479198, backing them out doesn't fix the issue. Most likely candidate is bug 452498 then.
Marking as blocking bug 452498 given the similarities to bug 496134. Requesting "blocking-1.9.1" given that this is a major regression in E4X functionality.
Blocks: upvar2
Flags: blocking1.9.1?
Assignee: general → brendan
Status: NEW → ASSIGNED
Attachment #381529 - Flags: review?(mrbkap)
The contributed (BEA, originally Crossgain) E4X test coverage seems pretty poor...

/be
Flags: wanted1.9.1?
Priority: -- → P2
Hardware: x86 → All
Target Milestone: --- → mozilla1.9.1
Wanted not blocking, since a workaround is to add an eval or with to the function. Fix essentially does that, is safe, so we should take.

/be
Flags: blocking1.9.1?
Workaround in action. First the bug:

$ cat /tmp/xmlns.js
(function() {var xmlns = new Namespace("xml", "http://www.w3.org/XML/1998/namespace"); var xml = <data />; xml.@xmlns::lang = "en-US"; print(xml.toXMLString());})()
$ ./Darwin_DBG.OBJ/js /tmp/xmlns.js
/tmp/xmlns.js:1: ReferenceError: xmlns is not defined

Now the workaround:

$ cat /tmp/xmlns2.js
(function() {eval('42'); var xmlns = new Namespace("xml", "http://www.w3.org/XML/1998/namespace"); var xml = <data />; xml.@xmlns::lang = "en-US"; print(xml.toXMLString());})()
$ ./Darwin_DBG.OBJ/js /tmp/xmlns2.js
<data xml:lang="en-US"/>

/be
Comment on attachment 381529 [details] [diff] [review]
essentially a one-line fix

Igor is up now and mrbkap is not, so looking for r+ from Igor -- this is an easy one, I want to get it into tm ASAP.

/be
Attachment #381529 - Flags: review?(igor)
Attachment #381529 - Flags: review?(igor) → review+
Comment on attachment 381529 [details] [diff] [review]
essentially a one-line fix

It seems there is a related issue with JSOP_DEFXMLNS: it sets fp->xmlNamespace only when fp->varobj is null. Thus, if a Call object for a lightweight would be requested via, for example, a debugger, then the second "default xml namespace" would not be visisble as it would set the namespace in the call object while js_GetDefaultXMLNamespace would continue to use fp->xmlNamespace. Marking any function using "default xml namespace" would allow to address this and eliminate AFAICS fp->xmlNamespace. But this is for another bug.
(In reply to comment #9)
> Marking any function using "default xml namespace" would allow to address this and eliminate AFAICS fp->xmlNamespace. But this is for another bug.

I mean marking any function using "default xml namespace" as heavyweight.
(In reply to comment #9)
> (From update of attachment 381529 [details] [diff] [review])
> It seems there is a related issue with JSOP_DEFXMLNS: it sets fp->xmlNamespace
> only when fp->varobj is null. Thus, if a Call object for a lightweight would be
> requested via, for example, a debugger, then the second "default xml namespace"
> would not be visisble as it would set the namespace in the call object while
> js_GetDefaultXMLNamespace would continue to use fp->xmlNamespace. Marking any
> function using "default xml namespace" would allow to address this and
> eliminate AFAICS fp->xmlNamespace. But this is for another bug.

Already in my patch queue for bug 471425.

/be
http://hg.mozilla.org/tracemonkey/rev/fb21a3a12180

/be
Whiteboard: fixed-in-tracemonkey
Attachment #381529 - Flags: review?(mrbkap) → review+
Brendan, thanks a lot for the quick turnaround!

Can we safely take this patch and apply it to our 1.9.1b4 XULRunner, or do we also need some changes that landed after b4 in 1.9.1?
(In reply to comment #13)
> Brendan, thanks a lot for the quick turnaround!
> 
> Can we safely take this patch and apply it to our 1.9.1b4 XULRunner, or do we
> also need some changes that landed after b4 in 1.9.1?

Should apply cleanly.

/be
http://hg.mozilla.org/mozilla-central/rev/fb21a3a12180
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.