337040 - 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

Status: RESOLVED FIXED

(Core :: DOM: Editor, defect, P3)

Description

[Robert Stopp (textrinum)]

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.

Comment 1

[Robert Stopp (textrinum)]

Attachment: a HTML document that shows the behavior

Comment 2

[Martijn Wargers (dead)]

I don't think this needs to be security sensitive. The crash part of the bug is already fixed.

Comment 3

[Boris Zbarsky [:bzbarsky]]

Is this an editor issue?  Is the behavior different if you don't turn on designMode?

Comment 4

[Martijn Wargers (dead)]

Yes, when designMode is not turned on, the content (written with document.write) is not erased.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Blake, you interested?  ;)

Comment 6

[Blake Kaplan (:mrbkap) (inactive)]

Attachment: 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...

Comment 7

[Blake Kaplan (:mrbkap) (inactive)]

Note that the subframe in the editable frame is *not* editable too.

Comment 8

[Kathleen :Brade]

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?

Comment 9

[Johnny Stenback (:jst)]

Comment on attachment 229042 [details] [diff] [review]
Fix

r+sr=jst

Comment 10

[Blake Kaplan (:mrbkap) (inactive)]

(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?

Comment 11

[Blake Kaplan (:mrbkap) (inactive)]

Fix checked into trunk.