Sample Document: <html> <head> <meta http-equiv="Content-Type" content="text/html;charset=utf-8" /> </head> <body> <div id="test"> asdf<asdf> </div> </body> </html> Expected result of innerHTML property of #test element: "asdf<asdf>" Actual result of innerHTML property of #test element: "asdf<asdf>"
Created attachment 26791 [details] innerHTML bug example You can see how webkit is confused with entity conversion of innerHTML.
Comment on attachment 26791 [details] innerHTML bug example Expected result (from Mozilla Firefox 3.0.5): asdf<asdf><br> asdf<asdf><br> asdf<asdf>><br> asdf<asdf><br> </asdf></asdf>> Actual Result: asdf<asdf><br> asdf<asdf><br> asdf<asdf>><br> asdf<asdf><br> </asdf></asdf>>
This problem happens also in Google Chrome 1.0.154.43.
I see the following with TOT: asdf<asdf><br> asdf<asdf><br> asdf<asdf>><br> asdf<asdf><br> </asdf></asdf>> That matches what Firefox gives.
Please also note that the previous WebKit behavior was formally correct, too - there is no fundamental reason to convert > to >, it's just something other browser do.
Yes, there's no problem with NOT converting closing '>' to '>', but some users of Textcube which I develope complain of this behaviour. (They and we didn't know before that this is a specific behaviour of Webkit.) Also I'm not sure that this behaviour may affect the backup-restore format called TTXML which has possibilities of contents processed by plain HTML <-> our own markup syntax conversion routines using innerHTML. We hope there be no side-effects from this.