Bug 7518 – attribute assignment not working in javascript

• Component: DOM
• Status: RESOLVED INVALID

[mitch gart]

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.

[Alexey Proskuryakov]

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!

[mitch gart]

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.

[Alexey Proskuryakov]

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.

[mitch gart]

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.

[Alexey Proskuryakov]

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?

[mitch gart]

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.

[Alexey Proskuryakov]

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.

[Alexey Proskuryakov]

This report doesn't have enough information for further action to be taken, closing.