Opened 6 years ago

Closed 5 years ago

#10601 closed Bug (fixed)

readOnly block element wrapped in P

Reported by: dggtydnk Owned by:
Priority: Normal Milestone:
Component: Core : Parser Version: 4.0 Beta
Keywords: Firefox Cc:

Description

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

Change History (5)

comment:1 Changed 6 years ago by Piotrek Koszuliński

Status: newconfirmed
Version: 4.1.2

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.

comment:2 Changed 6 years ago by Jakub Ś

Keywords: Firefox added
Version: 4.0 Beta

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

comment:3 Changed 6 years ago by 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.

comment:4 Changed 6 years ago by 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.

Last edited 6 years ago by Piotrek Koszuliński (previous) (diff)

comment:5 Changed 5 years ago by Piotrek Koszuliński

Resolution: fixed
Status: confirmedclosed

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.

Note: See TracTickets for help on using tickets.
© 2003 – 2019 CKSource – Frederico Knabben. All rights reserved. | Terms of use | Privacy policy