Opened 15 years ago

Closed 15 years ago

Last modified 14 years ago

#3684 closed Bug (fixed)

Edit area adding <p> when clicking in the edit area

Reported by: Damian Owned by: Garry Yao
Priority: Normal Milestone: CKEditor 3.0
Component: General Version:
Keywords: IBM Confirmed Review+ Cc:

Description

To reproduce:

  1. Open nightly sample
  2. Add a table with default settings
  3. Click in the editing area, next to the table (to the right of the table in LTR mode)

Results in a new <p> being added to the document. The document grows with every subsequent click.

<p>
	&nbsp;</p>

Reproduced on IE 6 and 7.

Attachments (4)

3684.patch (2.8 KB) - added by Garry Yao 15 years ago.
3684_2.patch (2.9 KB) - added by Garry Yao 15 years ago.
3684_3.patch (1.6 KB) - added by Garry Yao 15 years ago.
3684_4.patch (1.2 KB) - added by Garry Yao 15 years ago.

Download all attachments as: .zip

Change History (15)

comment:1 Changed 15 years ago by Garry Yao

Keywords: Confirmed added
Owner: set to Garry Yao
Status: newassigned

This's supposed to be fixed with #3657.

comment:2 Changed 15 years ago by Garry Yao

This has been proven to be out the range of #3657.
After some investigation, this's been caused by a feature from IE and Webkit:

  1. If 'mousedown' event is beside the table, move the selection right following the table;
  2. If 'Arrow Key' keypress event is happened at the last table cell editing position, move the selection out same as 1.

Which will result in a rare selection as:

<table>...</table>^

Now that our 'auto fixing block-less logic' commit a crime by "fixing" this into:

<table>...</table><p>^</p> // A new paragraph is established.

comment:3 Changed 15 years ago by Garry Yao

After talking with Fred, we found that not only happen for <table> and even happen for FF, reproduce with:

  1. Load the editor with:
    <hr />
    
  2. Click on the spaces around top margin of this hr;
  • Result: New line appended.

comment:4 Changed 15 years ago by Garry Yao

Keywords: Review? added

We already know that the fixBody functionality is for good of guarantee user could always type inside a enter block(p,div) , so if we found such a selection, it indicate that user is trying to exit from some block( maybe table, pre, hr ), so now we should not fix immediately, instead, we're checking whether there's already a 'enter block' around, if found, we'll simply moving into that paragraph, so user could continue to type inside it OR user could press enter now for new paragraph if he want.

comment:5 Changed 15 years ago by Garry Yao

Summary: [IE] Edit area adding <p> when clicking in the edit areaEdit area adding <p> when clicking in the edit area

Changed 15 years ago by Garry Yao

Attachment: 3684.patch added

comment:6 Changed 15 years ago by Frederico Caldeira Knabben

Keywords: Review- added; Review? removed

The proposed patch is not handling collapsed selections inside text nodes properly.

I would propose coming with a solution that makes all necessary checks "after" fixing the block to see if it works well. We can then compare both solutions and decide which one to (fix) and take.

Changed 15 years ago by Garry Yao

Attachment: 3684_2.patch added

Changed 15 years ago by Garry Yao

Attachment: 3684_3.patch added

comment:7 in reply to:  6 Changed 15 years ago by Garry Yao

Keywords: Review? added; Review- removed

Replying to fredck:

The proposed patch is not handling collapsed selections inside text nodes properly.

I would propose coming with a solution that makes all necessary checks "after" fixing the block to see if it works well. We can then compare both solutions and decide which one to (fix) and take.

  • 3684_2.patch is an enhancement of original approach;
  • 3684_3.patch is following your proposal;

Please compare these two while reviewing.

comment:8 Changed 15 years ago by Martin Kou

Keywords: Review- added; Review? removed

3684_3.patch is causing some strange selection shifts when the editor document has more than 1 non-enter mode blocks at the end. e.g.

  1. Open replacebyclass.html in IE.
  2. Press Enter at the end of the first paragraph to create a new paragraph.
  3. Inside the new paragraph, change the paragraph format to "Normal (DIV)".
  4. Press Enter again to create another DIV. Now you should have to DIV paragraphs at the end of the document.
  5. Click on the first DIV paragraph - no problem.
  6. Click on the second DIV paragraph - a P paragraph is created (which is ok), and the caret shifts into the newly created P (this is wrong).

Changed 15 years ago by Garry Yao

Attachment: 3684_4.patch added

comment:9 Changed 15 years ago by Garry Yao

Keywords: Review? added; Review- removed

It seems that in IE it's possible to leak selection into body even for block element like 'div' and 'blockquote', so we should disable the possibility of exiting from them with a new paragrah.
After the patch, it's still possible for user to exit from no matter what block. E.g, if you want to exit from, let's say a 'div' into a 'p', you can press enter at the end it, and change newly created 'div' into 'p'.

comment:10 Changed 15 years ago by Martin Kou

Keywords: Review+ added; Review? removed

comment:11 Changed 15 years ago by Garry Yao

Resolution: fixed
Status: assignedclosed

Fixed with [3672]. Click here for more info about our SVN system.

Note: See TracTickets for help on using tickets.
© 2003 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy