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

RESOLVED FIXED in mozilla1.9alpha1

Status

()

P3
normal
RESOLVED FIXED
13 years ago
12 years ago

People

(Reporter: robert.stopp, Assigned: mrbkap)

Tracking

({testcase})

Trunk
mozilla1.9alpha1
testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(2 attachments)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.3) Gecko/20060426 Firefox/1.5.0.3

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 1.5.0.0 - 1.5.0.2 this crashes the Browser.
In Version 1.5.0.3 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.
(Reporter)

Comment 1

13 years ago
Created attachment 221224 [details]
a HTML document that shows the behavior
(Reporter)

Updated

13 years ago
Depends on: 334515
(Reporter)

Updated

13 years ago
Version: unspecified → 1.5.0.x Branch
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
Keywords: testcase
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?
Group: security
Yes, when designMode is not turned on, the content (written with document.write) is not erased.
Blake, you interested?  ;)
(Reporter)

Updated

13 years ago
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...
Assignee: mozeditor → mrbkap
Status: NEW → ASSIGNED
Attachment #229042 - Flags: superreview?(jst)
Attachment #229042 - Flags: review?(jst)
Attachment #229042 - Flags: review?(brade)
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 8

12 years ago
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
Attachment #229042 - Flags: superreview?(jst)
Attachment #229042 - Flags: superreview+
Attachment #229042 - Flags: review?(jst)
Attachment #229042 - Flags: review+
(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: 12 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.