Closed Bug 318922 Opened 19 years ago Closed 19 years ago

E4X: invalid syntax to use a memory variable crashes Firefox

Categories

(Core :: JavaScript Engine, defect)

x86
Windows XP
defect
Not set
critical

Tracking

()

VERIFIED FIXED

People

(Reporter: BijuMailList, Assigned: brendan)

References

()

Details

(Keywords: verified1.8.0.1, verified1.8.1)

Attachments

(3 files, 1 obsolete file)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051202 Firefox/1.6a1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051202 Firefox/1.6a1 see TB12545982W, TB12545909Z, TB12545875H, TB12545808K run bookmarklet javascript:b=2;a=<a><b{b}>x</b{b}></a>; or at JSConsole execute b=2;a=<a><b{b}>x</b{b}></a>; invalid memory variable subsitution in E4X like <b{b}> crashes firefox Reproducible: Always Steps to Reproduce: click the "URL" of this bug
confirmed with firefox 1.5/winxp. I'll attach a stack as soon as my builds complete. Is there any reason other than this is a crash that you marked this bug as security sensitive?
Status: UNCONFIRMED → NEW
Ever confirmed: true
with ff1.5 h 0x00000000 n 0x003a0043 + s 0x0077005c "" - str 0x00010008 length 0x003a0043 - chars 0x0077005c "" CXX0030: Error: expression cannot be evaluated js_HashString(JSString * 0x00010008) line 2811 + 19 bytes js_AtomizeString(JSContext * 0x03ad4fe8, JSString * 0x00010008, unsigned int 0x00000000) line 650 + 9 bytes FoldXMLConstants(JSContext * 0x03ad4fe8, JSParseNode * 0x03fa5900, JSTreeContext * 0x00129af8) line 4426 + 15 bytes js_FoldConstants(JSContext * 0x03ad4fe8, JSParseNode * 0x03fa5900, JSTreeContext * 0x00129af8) line 4809 + 17 bytes js_FoldConstants(JSContext * 0x03ad4fe8, JSParseNode * 0x03fa59c8, JSTreeContext * 0x00129af8) line 4523 + 17 bytes js_FoldConstants(JSContext * 0x03ad4fe8, JSParseNode * 0x03fa5800, JSTreeContext * 0x00129af8) line 4523 + 17 bytes js_FoldConstants(JSContext * 0x03ad4fe8, JSParseNode * 0x03fa5b30, JSTreeContext * 0x00129af8) line 4547 + 17 bytes js_FoldConstants(JSContext * 0x03ad4fe8, JSParseNode * 0x03fa5b58, JSTreeContext * 0x00129af8) line 4554 + 23 bytes Statements(JSContext * 0x03ad4fe8, JSTokenStream * 0x03fa5480, JSTreeContext * 0x00129af8) line 1085 + 17 bytes js_CompileTokenStream(JSContext * 0x03ad4fe8, JSObject * 0x03bc9d10, JSTokenStream * 0x03fa5480, JSCodeGenerator * 0x00129af8) line 468 + 17 bytes CompileTokenStream(JSContext * 0x03ad4fe8, JSObject * 0x03bc9d10, JSTokenStream * 0x03fa5480, void * 0x03ad5030, int * 0x00000000) line 3581 + 26 bytes JS_CompileUCScriptForPrincipals(JSContext * 0x03ad4fe8, JSObject * 0x03bc9d10, JSPrincipals * 0x03a8a014, const unsigned short * 0x00129d88, unsigned int 0x0000001c, const char * 0x00129fac, unsigned int 0x00000001) line 3680 + 23 bytes JS_EvaluateUCScriptForPrincipals(JSContext * 0x03ad4fe8, JSObject * 0x03bc9d10, JSPrincipals * 0x03a8a014, const unsigned short * 0x00129d88, unsigned int 0x0000001c, const char * 0x00129fac, unsigned int 0x00000001, long * 0x00129cf4) line 4099 + 33 bytes nsJSContext::EvaluateString(const nsAString_internal & {...}, void * 0x03bc9d10, nsIPrincipal * 0x03a8a010, const char * 0x00129fac, unsigned int 0x00000001, const char * 0x00000000, nsAString_internal * 0x00129ff4, int * 0x00129f90) line 1061 + 67 bytes nsJSThunk::EvaluateScript(nsIChannel * 0x03fa5288) line 297 + 90 bytes nsJSChannel::InternalOpen(int 0x00000001, nsIStreamListener * 0x03fa53b0, nsISupports * 0x00000000, nsIInputStream * * 0x00000000) line 550 + 30 bytes nsJSChannel::AsyncOpen(nsJSChannel * const 0x03fa51f8, nsIStreamListener * 0x03fa53b0, nsISupports * 0x00000000) line 522 nsDocumentOpenInfo::Open(nsIChannel * 0x03fa51f8) line 224 + 18 bytes nsURILoader::OpenURI(nsURILoader * const 0x02def088, nsIChannel * 0x03fa51f8, int 0x00000000, nsIInterfaceRequestor * 0x03ace340) line 915 + 19 bytes nsDocShell::DoChannelLoad(nsIChannel * 0x03fa51f8, nsIURILoader * 0x02def088) line 6953 + 63 bytes nsDocShell::DoURILoad(nsIURI * 0x03fa5050, nsIURI * 0x00000000, int 0x00000001, nsISupports * 0x03a8a010, const char * 0x00000000, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000, int 0x00000001, nsIDocShell * * 0x00000000, nsIRequest * * 0x0012a4f4) line 6805 + 35 bytes nsDocShell::InternalLoad(nsDocShell * const 0x03ace3c8, nsIURI * 0x03fa5050, nsIURI * 0x00000000, nsISupports * 0x00000000, unsigned int 0x00000001, const unsigned short * 0x03fa51c0, const char * 0x00000000, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000, unsigned int 0x00000001, nsISHEntry * 0x00000000, int 0x00000001, nsIDocShell * * 0x00000000, nsIRequest * * ...) lin nsDocShell::LoadURI(nsDocShell * const 0x03ace3c8, nsIURI * 0x03fa5050, nsIDocShellLoadInfo * 0x03fa5158, unsigned int 0x00000000, int 0x00000001) line 793 + 84 bytes nsDocShell::LoadURI(nsDocShell * const 0x03ace3d8, const unsigned short * 0x03fa4db0, unsigned int 0x00000000, nsIURI * 0x00000000, nsIInputStream * 0x00000000, nsIInputStream * 0x00000000) line 2868 + 38 bytes XPTC_InvokeByIndex(nsISupports * 0x03ace3d8, unsigned int 0x00000008, unsigned int 0x00000005, nsXPTCVariant * 0x0012a944) line 102 XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode CALL_METHOD) line 2139 + 43 bytes XPC_WN_CallMethod(JSContext * 0x02ea7350, JSObject * 0x03b0c728, unsigned int 0x00000005, long * 0x03f3f7d8, long * 0x0012ac18) line 1444 + 14 bytes js_Invoke(JSContext * 0x02ea7350, unsigned int 0x00000005, unsigned int 0x00000000) line 1177 + 23 bytes js_Interpret(JSContext * 0x02ea7350, unsigned char * 0x0309c1bb, long * 0x0012b738) line 3522 + 15 bytes js_Invoke(JSContext * 0x02ea7350, unsigned int 0x00000002, unsigned int 0x00000006) line 1197 + 19 bytes fun_apply(JSContext * 0x02ea7350, JSObject * 0x03b0d388, unsigned int 0x00000002, long * 0x03f3f5f0, long * 0x0012b87c) line 1603 + 15 bytes js_Invoke(JSContext * 0x02ea7350, unsigned int 0x00000002, unsigned int 0x00000000) line 1177 + 23 bytes js_Interpret(JSContext * 0x02ea7350, unsigned char * 0x03b7f263, long * 0x0012c39c) line 3522 + 15 bytes js_Invoke(JSContext * 0x02ea7350, unsigned int 0x00000000, unsigned int 0x00000002) line 1197 + 19 bytes nsXPCWrappedJSClass::CallMethod(nsXPCWrappedJSClass * const 0x03b4ec48, nsXPCWrappedJS * 0x03efc280, unsigned short 0x0021, const nsXPTMethodInfo * 0x0314acc8, nsXPTCMiniVariant * 0x0012c6ec) line 1369 + 22 bytes nsXPCWrappedJS::CallMethod(nsXPCWrappedJS * const 0x03efc280, unsigned short 0x0021, const nsXPTMethodInfo * 0x0314acc8, nsXPTCMiniVariant * 0x0012c6ec) line 462 PrepareAndDispatch(nsXPTCStubBase * 0x03efc280, unsigned int 0x00000021, unsigned int * 0x0012c79c, unsigned int * 0x0012c78c) line 117 + 31 bytes SharedStub() line 147 nsAutoCompleteController::EnterMatch() line 1018 nsAutoCompleteController::HandleEnter(nsAutoCompleteController * const 0x03be91f8, int * 0x0012ca2c) line 275 XPTC_InvokeByIndex(nsISupports * 0x03be91f8, unsigned int 0x00000009, unsigned int 0x00000001, nsXPTCVariant * 0x0012ca2c) line 102 XPCWrappedNative::CallMethod(XPCCallContext & {...}, XPCWrappedNative::CallMode CALL_METHOD) line 2139 + 43 bytes XPC_WN_CallMethod(JSContext * 0x02ea7350, JSObject * 0x03bc9918, unsigned int 0x00000000, long * 0x03f3f528, long * 0x0012cd00) line 1444 + 14 bytes js_Invoke(JSContext * 0x02ea7350, unsigned int 0x00000000, unsigned int 0x00000000) line 1177 + 23 bytes js_Interpret(JSContext * 0x02ea7350, unsigned char * 0x03b831ac, long * 0x0012d820) line 3522 + 15 bytes js_Invoke(JSContext * 0x02ea7350, unsigned int 0x00000001, unsigned int 0x00000002) line 1197 + 19 bytes js_InternalInvoke(JSContext * 0x02ea7350, JSObject * 0x03b0d388, long 0x03c83ae0, unsigned int 0x00000000, unsigned int 0x00000001, long * 0x0012da1c, long * 0x0012da18) line 1274 + 20 bytes JS_CallFunctionValue(JSContext * 0x02ea7350, JSObject * 0x03b0d388, long 0x03c83ae0, unsigned int 0x00000001, long * 0x0012da1c, long * 0x0012da18) line 4158 + 31 bytes nsJSContext::CallEventHandler(JSObject * 0x03b0d388, JSObject * 0x03c83ae0, unsigned int 0x00000001, long * 0x0012da1c, long * 0x0012da18) line 1411 + 33 bytes nsJSEventListener::HandleEvent(nsJSEventListener * const 0x03f55c80, nsIDOMEvent * 0x03f9ac50) line 186 + 54 bytes nsXBLPrototypeHandler::ExecuteHandler(nsIDOMEventReceiver * 0x03fa19d8, nsIDOMEvent * 0x03f9ac50) line 505 nsXBLKeyEventHandler::HandleEvent(nsXBLKeyEventHandler * const 0x03b6e420, nsIDOMEvent * 0x03f9ac50) line 153 nsEventListenerManager::HandleEventSubType(nsListenerStruct * 0x03b6e580, nsIDOMEvent * 0x03f9ac50, nsIDOMEventTarget * 0x03fa19d8, unsigned int 0x00000004, unsigned int 0x00000004) line 1685 + 20 bytes nsEventListenerManager::HandleEvent(nsEventListenerManager * const 0x03b5f078, nsPresContext * 0x02efa890, nsEvent * 0x0012f5e0, nsIDOMEvent * * 0x0012ed8c, nsIDOMEventTarget * 0x03fa19d8, unsigned int 0x00000004, nsEventStatus * 0x0012f3b0) line 1789 nsXULElement::HandleDOMEvent(nsPresContext * 0x02efa890, nsEvent * 0x0012f5e0, nsIDOMEvent * * 0x0012ed8c, unsigned int 0x00000004, nsEventStatus * 0x0012f3b0) line 2153 nsXULElement::HandleDOMEvent(nsPresContext * 0x02efa890, nsEvent * 0x0012f5e0, nsIDOMEvent * * 0x0012ed8c, unsigned int 0x00000004, nsEventStatus * 0x0012f3b0) line 2132 nsXULElement::HandleDOMEvent(nsPresContext * 0x02efa890, nsEvent * 0x0012f5e0, nsIDOMEvent * * 0x0012ed8c, unsigned int 0x00000004, nsEventStatus * 0x0012f3b0) line 2132 nsGenericElement::HandleDOMEvent(nsPresContext * 0x02efa890, nsEvent * 0x0012f5e0, nsIDOMEvent * * 0x0012ed8c, unsigned int 0x00000007, nsEventStatus * 0x0012f3b0) line 2117 nsHTMLInputElement::HandleDOMEvent(nsPresContext * 0x02efa890, nsEvent * 0x0012f5e0, nsIDOMEvent * * 0x00000000, unsigned int 0x00000001, nsEventStatus * 0x0012f3b0) line 1395 + 31 bytes PresShell::HandleEventInternal(nsEvent * 0x0012f5e0, nsIView * 0x02f771b0, unsigned int 0x00000001, nsEventStatus * 0x0012f3b0) line 6367 + 64 bytes PresShell::HandleEvent(PresShell * const 0x02e460a0, nsIView * 0x02f771b0, nsGUIEvent * 0x0012f5e0, nsEventStatus * 0x0012f3b0, int 0x00000001, int & 0x00000001) line 6203 + 25 bytes nsViewManager::HandleEvent(nsView * 0x02f771b0, nsGUIEvent * 0x0012f5e0, int 0x00000000) line 2514 nsViewManager::DispatchEvent(nsViewManager * const 0x02f6f130, nsGUIEvent * 0x0012f5e0, nsEventStatus * 0x0012f530) line 2246 + 20 bytes HandleEvent(nsGUIEvent * 0x0012f5e0) line 174 nsWindow::DispatchEvent(nsWindow * const 0x02f77284, nsGUIEvent * 0x0012f5e0, nsEventStatus & nsEventStatus_eIgnore) line 1252 + 10 bytes nsWindow::DispatchWindowEvent(nsGUIEvent * 0x0012f5e0) line 1273 nsWindow::DispatchKeyEvent(unsigned int 0x00000083, unsigned short 0x0000, unsigned int 0x0000000d, long 0x001c0001, unsigned int 0x00000000) line 3448 + 15 bytes nsWindow::OnKeyDown(unsigned int 0x0000000d, unsigned int 0x0000001c, long 0x001c0001) line 3586 nsWindow::ProcessMessage(unsigned int 0x00000100, unsigned int 0x0000000d, long 0x001c0001, long * 0x0012fb58) line 4487 + 32 bytes nsWindow::WindowProc(HWND__ * 0x000b013e, unsigned int 0x00000100, unsigned int 0x0000000d, long 0x001c0001) line 1434 + 27 bytes USER32! 77d48734() USER32! 77d48816() USER32! 77d489cd() USER32! 77d48a10() nsAppShell::Run(nsAppShell * const 0x02d92680) line 135 nsAppStartup::Run(nsAppStartup * const 0x02d925e0) line 150 + 26 bytes XRE_main(int 0x00000001, char * * 0x003f7d60, const nsXREAppData * 0x0042201c kAppData) line 2313 + 35 bytes main(int 0x00000001, char * * 0x003f7d60) line 61 + 18 bytes mainCRTStartup() line 338 + 17 bytes KERNEL32! 7c816d4f()
I don't think this is actually invalid syntax. The productions for XMLElement seem to allow all sorts of weird things, including "var x = < xml />" (was that intentional?). The actual problem here is that we end up assuming that we get a pn_arity = PN_NAME parsenode for TOK_XMLNAME, when in this case we get a PN_LIST. I'll attach a potential patch which seems to do the right thing (and which I believe is correct, since we can't fold such productions anyway).
Priority: -- → P1
Target Milestone: --- → mozilla1.9alpha
Attached patch Potential fix (obsolete) (deleted) — Splinter Review
If we're dealing with a PN_LIST, bail.
Assignee: general → mrbkap
Status: NEW → ASSIGNED
Attachment #204967 - Flags: review?(brendan)
Crashes on Linux too. (In reply to comment #1) > Is there any reason other than this is a crash that you marked this bug as > security sensitive? I would like developers to evaluate and confirm there is no security risk.
also crashes for javascript: b=2; a=<a><b c{b}="2">x</b></a>; (In reply to comment #3) > I don't think this is actually invalid syntax. The productions for XMLElement > seem to allow all sorts of weird things, including "var x = < xml />" > (was that intentional?). As code javascript: b='c'; a=<a><b {b}='c'>x</b></a>; alert(a); javascript: b='c'; a=<a><b c={b}>x</b></a>; alert(a); are valid XML tag syntax but javascript: try{a='';b='"'; eval('a=<a><b c={b}x">x</b></a>'); }catch(e){alert(e)} javascript: try{a='';b='"'; eval('a=<a><b c="x{b}>x</b></a>'); }catch(e){alert(e)} javascript: try{a='';b='x'; eval('a=<a><b c={b}"x">x</b></a>'); }catch(e){alert(e)} javascript: try{a='';b='x'; eval('a=<a><b c="x"{b}>x</b></a>'); }catch(e){alert(e)} are SyntaxError: invalid XML tag syntax and instead of javascript: b=2; a=<a><b{b}>x</b{b}></a>; A programer could achive the same result by javascript: b=2; a=<a><{"b"+b}>x</{"b"+b}></a>; alert(a); IMHO we should consider javascript: b=2; a=<a><b{b}>x</b{b}></a>; javascript: b=2; a=<a><b c{b}="2">x</b></a>; as invalid XML tag syntax. if the E4X not specify it or reads otherwise, Mozzila should rise this inconsistency at ECMA. But I feel all the following should be a valid cyntax uri="http://a.uri/"; p="p"; n = new Namespace(uri); x = <t xmlns:p={uri}> <{uri}:u>42</p:u> </t>; x = <t xmlns:p={uri1}> <{p}:u>42</p:u> </t>; x = <t xmlns:p={uri1}> <{n}:u>42</p:u> </t>; (PS: also it is no crashing, good...) any way x = <t xmlns:p={"x", 1, uri}> <p:u>42</p:u> </t>; x = <t xmlns:p={(function(){return uri})()}> <p:u>42</p:u> </t>; are valid. But not x = <t xmlns:p={var d; uri}> <p:u>42</p:u> </t>; and it should not be as "var d; uri" is not an expression, but two statments
Attached file E4X syntax test suite (deleted) —
Adding a test page... While creating the test page I see some strange things!!! for "m='x';a=new XML(m);" "typeof a" gives "xml" value as "x" toXMLString as "x" !!!! Also works same way for m=1; but not for m={a:1,b:'x'}; or m=[1]; ---- ????? If we had extened XML() to a syntax XML(thing_2_xml, [rootNodeName default="root", [subNodeName default="item", [subNode2Name default="item", .... [subNodeNName default="item"]...]]]); it would have been easy (faster) to convert a JSON object ( http://www.json.org/ ) a XML like XML({a:1,b:'x'}) gives <root> <a>1</a> <b>x</b> </root> like XML([1,2,[3,4,[5,6]]]); gives <root> <item>1</item> <item>2</item> <item> <item>3</item> <item>4</item> <item> <item>5</item> <item>6</item> </item> </item> </root>
(In reply to comment #6) > IMHO we should consider > javascript: b=2; a=<a><b{b}>x</b{b}></a>; > javascript: b=2; a=<a><b c{b}="2">x</b></a>; > as invalid XML tag syntax. > > if the E4X not specify it or reads otherwise, > Mozzila should rise this inconsistency at ECMA. I did, but Mozilla joined ECMA too late to change the ECMA-357 spec. The ECMA-357 E4X spec, which I did not contribute to except with last-minute spot-fixes, intentionally included a loose "cover grammar" for XML, which allows for all sorts of oddments, including multiple attributes expanded (and not all escaped properly) from one attribute value {expression}. The grammar for the ISO version of the spec is tighter. /be
Attached patch fix (deleted) — Splinter Review
Need to dump what's in accum into a text node, update pnp etc., and keep looping trying to fold other stuff in pn's list. /be
Attachment #204967 - Attachment is obsolete: true
Attachment #204998 - Flags: review?(mrbkap)
Attachment #204967 - Flags: review?(brendan)
Flags: blocking1.8.1+
Flags: blocking1.8.0.1?
Priority: P1 → --
Target Milestone: mozilla1.9alpha → ---
Comment on attachment 204998 [details] [diff] [review] fix Ah, yeah, I guessed I was missing something.
Attachment #204998 - Flags: review?(mrbkap) → review+
Fixed on trunk. This bug is not security-sensitive because the worst that can happen is a wild pointer load (not store), which will crash. It still should be fixed soon in available release vehicles. /be
Group: security
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
> I did, but Mozilla joined ECMA too late to change the ECMA-357 spec. Thanks... > > The grammar for the ISO version of the spec is tighter. good to know... Thanks all for fixing it quick...
Tested on Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20051205 Firefox/1.6a1 Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a1) Gecko/20051205 Firefox/1.6a1 with https://bugzilla.mozilla.org/attachment.cgi?id=204986 Result: fix makes some other crashes !!!! so reopening bug see following 1, 2, 3, 4 are same XML, but 3 and 4 gives a funny "SyntaxError: syntax error" when 1 and 2 works just fine 1. b='b'; a=<a><{b}b>x</bb></a>; 2. b='b'; a=<a><!-- --><{b}b> x </bb></a>; 3. b='b'; a=<a> <{b}b>x</bb> </a>; 4. b='b'; a=<a> <{b}b>x</bb></a>; following also give the same funny "SyntaxError: syntax error" // test 11 b='b'; a=<a> <{b+'b'}>x</bb> </a>; // test 12 b='c'; a=<a> <b {b+'c'}='c'>x</b> </a>; // test 16 u='http://a.uri/'; a=<a xmlns:p={'x',1,u}> <p:b>x</p:b> </a>; // test 20 m='<m><n>o</n></m>'; a=<a> <b>x {m} z</b> </a>; And following are crashing // test 17 u='http://a.uri/'; a=<a xmlns:p={(function(){return u})()}> <p:b>x</p:b> </a>; // test 19 m=<m><n>o</n></m>; a=<a> <b>x {m} z</b> </a>; // test 34 m=<m><n>o</n></m>; a=<a> <{m}>x z</{m}> </a>; // test 35 m=<m>o</m>; a=<a> <{m}>x z</{m}> </a>; I thought to catch the funny "SyntaxError: syntax error" like try{ b='b'; a=<a> <{b}b>x</bb> </a>; }catch(e){ listobj(e); } That time it gave me crash TB12647959G TB12647913Y TB12647699K TB12647677Z TB12647635X TB12647541X Please unit test with attachment# 204986 [details] before releasing code https://bugzilla.mozilla.org/attachment.cgi?id=204986 https://bugzilla.mozilla.org/show_bug.cgi?id=318922
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Sorry, will retest in full. Thanks, /be
Assignee: mrbkap → brendan
Status: REOPENED → NEW
Attached patch one-line fix (deleted) — Splinter Review
r=mrbkap, stupid bug (why doesn't GCC warn when a case is missing? We tried removing the default case from the big switch in js_EmitTree, but no warning for the missing TOK_XMLSPACE case was issued). /be
Attachment #205176 - Flags: review+
Blocks: js1.6rc1
Too stupid not to fix for 1.8.0.1. /be
Status: NEW → RESOLVED
Closed: 19 years ago19 years ago
Flags: blocking1.8.0.1? → blocking1.8.0.1+
Resolution: --- → FIXED
Attachment #205176 - Flags: approval1.8.0.1?
Attachment #204998 - Flags: approval1.8.0.1?
(In reply to comment #15) > one-line fix Thanks... Just curious... Are the following still invalid syntax? uri="http://a.uri/"; p="p"; n = new Namespace(uri); n2 = new Namespace("p2", uri); x = <t xmlns:p={uri}> <{uri}:u>42</p:u> </t>; x = <t xmlns:p={uri}> <{p}:u>42</p:u> </t>; x = <t xmlns:p={uri}> <{n}:u>42</p:u> </t>; x = <t xmlns:p={uri}> <{n2}:u>42</p:u> </t>; if so, please make sure following remains invalid uri="http://a.uri/"; p="p"; n3 = new Namespace("p", uri + "/something"); n4 = new Namespace(uri + "/something"); x = <t xmlns:p={uri}> <{n3}:u>42</p:u> </t>; x = <t xmlns:p={uri}> <{n4}:u>42</p:u> </t>; can wait for seeing fix.
(In reply to comment #17) > (In reply to comment #15) > > one-line fix > Thanks... > > Just curious... Are the following still invalid syntax? Sorry, I will have to find the ISO version of ECMA-357, ISO-16537 IIRC, and read it carefully. Feel free to do the same if you can find an online version of it. /be
Checking in regress-318922.js; /cvsroot/mozilla/js/tests/e4x/Regress/regress-318922.js,v <-- regress-318922.js initial revision: 1.1 verified with today's trunk/winxp.
Status: RESOLVED → VERIFIED
Flags: testcase+
*** Bug 319459 has been marked as a duplicate of this bug. ***
Comment on attachment 204998 [details] [diff] [review] fix Please land on 1.8 and 1.8.1 branches.
Attachment #204998 - Flags: approval1.8.1+
Attachment #204998 - Flags: approval1.8.0.1?
Attachment #204998 - Flags: approval1.8.0.1+
Comment on attachment 205176 [details] [diff] [review] one-line fix Please land on 1.8 and 1.8.1 branches.
Attachment #205176 - Flags: approval1.8.1+
Attachment #205176 - Flags: approval1.8.0.1?
Attachment #205176 - Flags: approval1.8.0.1+
Fixed on the 1.8 and 1.8.0 branches. /be
v.fixed on 1.8.0.1 with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060104 Firefox/1.5.0.1
Keywords: fixed1.8.0.1
v 2006-01-11 1.8.0.1, 1.8.1, trunk windows/linux/mac
Keywords: fixed1.8.1
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: