The default bug view has changed. See this FAQ.

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

RESOLVED FIXED in mozilla1.9.1

Status

()

Core
JavaScript Engine
P2
critical
RESOLVED FIXED
8 years ago
8 years ago

People

(Reporter: Matteo Ferretti, Assigned: brendan)

Tracking

({regression})

1.9.1 Branch
mozilla1.9.1
regression
Points:
---
Dependency tree / graph
Bug Flags:
wanted1.9.1 ?

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fixed-in-tracemonkey)

Attachments

(1 attachment)

(Reporter)

Description

8 years ago
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.

Comment 1

8 years ago
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

Updated

8 years ago
Blocks: 393966

Comment 2

8 years ago
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.

Comment 3

8 years ago
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: 452498
Flags: blocking1.9.1?
(Assignee)

Comment 4

8 years ago
Created attachment 381529 [details] [diff] [review]
essentially a one-line fix
Assignee: general → brendan
Status: NEW → ASSIGNED
Attachment #381529 - Flags: review?(mrbkap)
(Assignee)

Comment 5

8 years ago
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
(Assignee)

Comment 6

8 years ago
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?
(Assignee)

Comment 7

8 years ago
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
(Assignee)

Comment 8

8 years ago
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)

Updated

8 years ago
Attachment #381529 - Flags: review?(igor) → review+

Comment 9

8 years ago
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.

Comment 10

8 years ago
(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.
(Assignee)

Comment 11

8 years ago
(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
(Assignee)

Comment 12

8 years ago
http://hg.mozilla.org/tracemonkey/rev/fb21a3a12180

/be
Whiteboard: fixed-in-tracemonkey

Updated

8 years ago
Attachment #381529 - Flags: review?(mrbkap) → review+

Comment 13

8 years ago
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?
(Assignee)

Comment 14

8 years ago
(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

Comment 15

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