Bug 20654 - contenteditable iframe changes contents
Summary: contenteditable iframe changes contents
Status: RESOLVED DUPLICATE of bug 11947
Alias: None
Product: WebKit
Classification: Unclassified
Component: HTML Editing (show other bugs)
Version: 312.x
Hardware: Macintosh OS X 10.5
: P1 Major
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-04 18:14 PDT by Philip Tucker
Modified: 2008-09-08 03:38 PDT (History)
2 users (show)

See Also:


Attachments
same test as an attachment (396 bytes, text/html)
2008-09-08 03:31 PDT, Alexey Proskuryakov
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Philip Tucker 2008-09-04 18:14:05 PDT
We've hit another Webkit issue in Google Docs. It seems that Webkit converts   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>
Comment 1 Alexey Proskuryakov 2008-09-08 03:31:35 PDT
Created attachment 23245 [details]
same test as an attachment

Attaching to make testing easier.
Comment 2 Alexey Proskuryakov 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 ***