WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
RESOLVED DUPLICATE of
bug 11947
20654
contenteditable iframe changes contents
https://bugs.webkit.org/show_bug.cgi?id=20654
Summary
contenteditable iframe changes contents
Philip Tucker
Reported
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 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.
Top of Page
Format For Printing
XML
Clone This Bug