User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:220.127.116.11) Gecko/20060426 Firefox/18.104.22.168 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:22.214.171.124) Gecko/20060426 Firefox/126.96.36.199 bug 334515 seems to only half fixed. If designMode is "on" on an iframe and an document.write('<iframe src="xy"><\/iframe>') and then document.close() is called on that Iframe, the contents seems to be deleted and the returned iframe seems not to be the orignal but is editable (maybe the written). If document.close() is not called, the behavior is normal but wrong. So the Problem is "document.close()" that not works correct. Reproducible: Always Steps to Reproduce: see Attachment Actual Results: In Version 188.8.131.52 - 184.108.40.206 this crashes the Browser. In Version 220.127.116.11 the Behavior is like discribed. Expected Results: render the written HTML after document.close() The popular Editor HTMLArea (used in blog software, typo 3 and many other CMS) is affected because the initialisation of an editable document is like discribed.
I don't think this needs to be security sensitive. The crash part of the bug is already fixed.
Assignee: nobody → mozeditor
Severity: critical → normal
Status: UNCONFIRMED → NEW
Component: Security → Editor
Ever confirmed: true
Product: Firefox → Core
QA Contact: firefox
Version: 1.5.0.x Branch → Trunk
Is this an editor issue? Is the behavior different if you don't turn on designMode?
Yes, when designMode is not turned on, the content (written with document.write) is not erased.
Blake, you interested? ;)
Summary: document.close() deletes width document.write() written HTML if in that HTMl an iframe-element is included and designMode on the document to be written is on. relates to bug 334515 → document.close() deletes with document.write() written HTML if in that HTMl an iframe-element is included and designMode on the document to be written is on. relates to bug 334515
Created attachment 229042 [details] [diff] [review] Fix The fix for bug 283897 missed this case: we don't want to change mCanCreateEditor if we're getting a notification for a document that we don't care about. I'm not sure who should review this...
OS: Windows XP → All
Priority: -- → P3
Hardware: PC → All
Target Milestone: --- → mozilla1.9alpha
Note that the subframe in the editable frame is *not* editable too.
Comment on attachment 229042 [details] [diff] [review] Fix r=brade How odd that no one caught the * before it landed. Has anyone tested this in Composer (suite?) to know if this breaks frame editing?
Attachment #229042 - Flags: review?(brade) → review+
Comment on attachment 229042 [details] [diff] [review] Fix r+sr=jst
(In reply to comment #8) > Has anyone tested this in Composer (suite?) to know if this breaks frame > editing? I'm note so savvy using editor. What tests can I try to confirm that I haven't broken anything?
Fix checked into trunk.
Status: ASSIGNED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.