readOnly block element wrapped in P

[dggtydnk]

When a block level element is set to readOnly, it is being wrapped in a P tag. Given the following HTML in the demo page:

<div id="test">
  <ul>
    <li>First bullet</li>
  </ul>
</div>

If the div#test is set to readOnly using the following code:

CKEDITOR.instances.editor2.document.$.getElementById("test").contentEditable=false;

Once set to readOnly, if you view the source using the Source button, you end up with:

<p>&nbsp;
<div contenteditable="false" id="test">
<ul contenteditable="false">
	<li>First bullet</li>
</ul>
</div>
</p>

I would expect the DIV not be wrapped in the P.

This seems to be specific to Firefox. The same test seems to pass in IE and Chrome

[Piotrek Koszuliński]

Easier TC - set this in source mode:

<div contenteditable="false" id="test">
<ul contenteditable="false">
	<li>First bullet</li>
</ul>
</div>

And switch to WYSIWYG.

[Jakub Ś]

NOTE: Perhaps readOnly term should be dropped here as it can get mistaken with editor readOnly

Problem can be reproduced in Firefox only from CKEditor 4.0 beta

[Piotrek Koszuliński]

This issue is caused by ​https://bugzilla.mozilla.org/show_bug.cgi?id=911201

Unfortunately, only a dirty hack, removing that <br> after data loading could help.

[Piotrek Koszuliński]

Actually, I'm wrong, because I was thinking about the issue that causes this one. The original issue, which reported on Bugzilla, is that FF inserts bogus <br> after data is set. Of course, if that issue was fixed by the Mozilla team, it would also fix this one (which is related to processing HTML broken by FF), but I believe that we can try to find a solution inside the data processor to at least have clean output data.

[Piotrek Koszuliński]

We fixed that in CKEditor 4.3. Leading <br> is removed when processing data, so no autoparagraphing happens. We decided that we should not touch the live DOM because FF was recreating that <br> when selection was changing.