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.
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!
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.
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.
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.
Created attachment 6813 [details] 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?
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.
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.
This report doesn't have enough information for further action to be taken, closing.