7518 2006-02-28 13:44:38 -0800 attribute assignment not working in javascript 2006-11-26 04:15:42 -0800 1 1 1 Unclassified WebKit DOM 416.x Mac OS X 10.4 RESOLVED INVALID P2 Normal --- 7602 1 mitch.gart webkit-unassigned ap ian oldest_to_newest 34456 0 mitch.gart 2006-02-28 13:44:38 -0800 In this code var link = document.createElement("a"); link.name = link.innerHTML = childNodes[i].getAttribute("name"); childNodes[i].getAttribute("name") returns a string that contains a Euro char (0x20ac). What are the values of link.name and link.innerHTML after this assignment? Link.innerHTML contains the correct string, and link.name doesn't. The Euro has been replaced with a hex 80 character. It has nothing to do with the double assignment or the order, it's just that one attribute seems to accept the Euro and the other doesn't. The code as written is fine in IE and Firefox but not Safari. 34461 1 ap 2006-02-28 14:03:32 -0800 Reporter, could you please attach a complete test case? There are quite a few factors that could potentially affect the behavior and that we would have to guess about otherwise. In any case, thank you for reporting this! 34657 2 mitch.gart 2006-03-01 11:07:37 -0800 There's a bug here somewhere but I wasn't able to get it to fail reliably for a simple case. I can't put my finger on exactly what the bug was. var link = document.createElement("a"); link.name = link.innerHTML = childNodes[i].getAttribute("name"); fails, but var link = document.createElement("a"); link.innerHTML = childNodes[i].getAttribute("name"); link.name = link.innerHTML; works correctly. I got the problem in my web application code fixed, and then spent a bunch of extra time trying to isolate the Safari bug, and couldn't. 34701 3 ap 2006-03-01 22:05:58 -0800 So, it had something to do with double assignment, after all? That's pretty weird... Thank you for the time you spent on isolating the problem! If you can afford to spend some more time, could you please try the following? 1) Is the problem reproducible in recent nightly builds from <http://nightly.webkit.org>? 2) What is logged to the console if you insert the following snippet before and after the troublesome part: console.log(escape(childNodes[i].getAttribute("name"))); console.log(escape(link.innerHTML)); console.log(escape(link.name)); The JavaScript console is accessible via Safari debug menu, I assume you already have it enabled. 34725 4 mitch.gart 2006-03-02 07:05:14 -0800 link.name = link.innerHTML = value2Html(childNodes[i].getAttribute("name")); console.log("attr: " + escape(childNodes[i].getAttribute("name"))); console.log("innerHTML: " + escape(link.innerHTML)); console.log("name: " + escape(link.name)); prints attr: Euro%80 innerHTML: Euro%U20AC name: Euro%80 The value that I put in the attribute was Euro€ or Euro\u20AC This is so weird. It seems like the double assignment isn't quite working, only I wrote a little stand-alone javascript program and double assignments seem to work fine. I can't make up a mental model of why this is failing. 34882 5 6813 ap 2006-03-02 13:12:09 -0800 Created attachment 6813 test case This test case shows a result of double assignment being different from a result of two assignments. It also shows that WebKit handles \u0080 (Unicode code point "nbsp control") in a pretty strange manner. Assuming this is what happens in the real code, we have one more major mystery left - how this code point found its way into the name attribute. Please note that %80 means Euro in many encodings, including Latin-1. Could it be that the real application specifies an encoding in HTTP headers or in an HTTP-Equiv meta, and your reduced tests don't? Maybe there is a mismatch between the actual and specified encodings? 34889 6 mitch.gart 2006-03-02 13:58:24 -0800 I put the console.log lines (temporarily) into the real application, not into a small test program. So whatever encoding was in effect for one line should have also been in effect for the other line. 35883 7 ap 2006-03-11 03:35:09 -0800 Reporter, please note that the fix in bug 7602 will likely break your workaround - U+0080 will no longer be mistakenly converted to U+20AC during parsing (i.e. assigning to innerHTML). You write that childNodes[i].getAttribute("name") contains %80, even after you put %U20AC there. This probably indicates that there is some other bug besides 7602, but I could not reproduce such behavior myself. 44245 8 ap 2006-11-26 04:15:42 -0800 This report doesn't have enough information for further action to be taken, closing. 6813 2006-03-02 13:12:09 -0800 2006-03-02 13:12:09 -0800 test case euro.html text/html 777 ap PGh0bWw+CjxoZWFkPgo8bWV0YSBodHRwLWVxdWl2PSJDb250ZW50LVR5cGUiIGNvbnRlbnQ9InRl eHQvaHRtbDsgY2hhcnNldD11cy1hc2NpaSI+CjwvaGVhZD4KPGJvZHk+CjxzY3JpcHQ+CnZhciBs aW5rID0gZG9jdW1lbnQuY3JlYXRlRWxlbWVudCgiYSIpOwoKbGluay5uYW1lID0gbGluay5pbm5l ckhUTUwgPSAiRXVyb1x1MDA4MCI7CmRvY3VtZW50LndyaXRlKCI8cD5pbm5lckhUTUw6ICIgKyBs aW5rLmlubmVySFRNTCArICIgKCIgKyBlc2NhcGUobGluay5pbm5lckhUTUwpICsgIik8L3A+Iik7 CmRvY3VtZW50LndyaXRlKCI8cD5uYW1lOiAiICsgbGluay5uYW1lICsgIiAoIiArIGVzY2FwZShs aW5rLm5hbWUpICsgIik8L3A+Iik7CgpsaW5rLm5hbWUgPSBsaW5rLmlubmVySFRNTDsKZG9jdW1l bnQud3JpdGUoIjxwPm5hbWU6ICIgKyBsaW5rLm5hbWUgKyAiICgiICsgIGVzY2FwZShsaW5rLm5h bWUpICsgIik8L3A+Iik7CgpsaW5rLm5hbWUgPSBsaW5rLmlubmVySFRNTCA9ICJFdXJvXHUyMEFD IjsKZG9jdW1lbnQud3JpdGUoIjxwPmlubmVySFRNTDogIiArIGxpbmsuaW5uZXJIVE1MICsgIiAo IiArIGVzY2FwZShsaW5rLmlubmVySFRNTCkgKyAiKTwvcD4iKTsKZG9jdW1lbnQud3JpdGUoIjxw Pm5hbWU6ICIgKyBsaW5rLm5hbWUgKyAiICgiICsgZXNjYXBlKGxpbmsubmFtZSkgKyAiKTwvcD4i KTsKCmRvY3VtZW50LndyaXRlKCI8cD4iICsgIkV1cm+AICgiICsgZXNjYXBlKCJFdXJvgCIpICsg Iik8L3A+Iik7Cjwvc2NyaXB0Pgo8L2JvZHk+CjwvaHRtbD4K