Bug 20654

Summary: contenteditable iframe changes contents
Product: WebKit Reporter: Philip Tucker <ptucker>
Component: HTML EditingAssignee: Nobody <webkit-unassigned>
Status: RESOLVED DUPLICATE    
Severity: Major CC: ap, ptucker
Priority: P1    
Version: 312.x   
Hardware: Mac   
OS: OS X 10.5   
Attachments:
Description Flags
same test as an attachment none

Philip Tucker
Reported 2008-09-04 18:14:05 PDT
We've hit another Webkit issue in Google Docs. It seems that Webkit converts &nbsp; to \u00A0 in content-editable mode. I'm guessing it does the same for other entities. This really messes us up with our editor because it looks to us like a user change. Is this a known issue, and is there a workaround? Sample HTML: <html><head> <script> var myBody = null; function init() { myBody = document.getElementById('iframe').contentWindow.document.body; myBody.innerHTML = "hello&nbsp;world"; myBody.contentEditable = true; } function foo() { alert(myBody.innerHTML); } </script> </head><body onload="init();"> <iframe id="iframe" src=""></iframe> <input type="button" value="clickme" onclick="foo();"> </body>
Attachments
same test as an attachment (396 bytes, text/html)
2008-09-08 03:31 PDT, Alexey Proskuryakov 		no flags
Details
View All Add attachment proposed patch, testcase, etc.
Alexey Proskuryakov
Comment 1 2008-09-08 03:31:35 PDT
Created attachment 23245 [details] same test as an attachment Attaching to make testing easier.
Alexey Proskuryakov
Comment 2 2008-09-08 03:38:36 PDT
This is already fixed in nightlies. Either behavior is correct, but we had to match other browsers on this for compatibility. I don't have any workaround to recommend, other than saying that innerHTML is not documented to preserve markup byte to byte, so relying on it is inherently unsafe. *** This bug has been marked as a duplicate of 11947 ***
Note You need to log in before you can comment on or make changes to this bug.