Opened 15 years ago

Closed 11 years ago

#2403 closed New Feature (fixed)

Enforce EnterMode

Reported by: Neil Jenkins Owned by:
Priority: Normal Milestone:
Component: UI : Enter Key Version: 3.0
Keywords: HasPatch Cc: robmueller


This is similar to #1464 (possibly a duplicate?).

When the enter mode is set to 'div' and you are inside a preexisting <p>, hitting enter inserts a new <p> not a <div>. Now I understand that this is sometimes useful, but I'm currently using FCKeditor for online email composition, and here our customers expect hitting enter to always give them one space, and due to wanting to support bi-directional support we can't use br mode.

The fix for this is very simple - I've added a new preference FCKEditor.ForceEnterMode which takes a boolean value (and should probably default to false). When set to true it will always use the given tag, even if it is splitting the opposite tag.

I've attached a patch.

Attachments (3)

enterKeyPatch.diff (646 bytes) - added by Neil Jenkins 15 years ago.
userpatch_2403.patch (893 bytes) - added by Wojciech Olchawa 15 years ago.
forceenter.patch (1.4 KB) - added by robmueller 15 years ago.
Updated patch

Download all attachments as: .zip

Change History (11)

Changed 15 years ago by Neil Jenkins

Attachment: enterKeyPatch.diff added


comment:1 Changed 15 years ago by Neil Jenkins

Sorry, there was a bug in the original patch where if you were inside a list, hitting enter would give you a new line rather than a new list item. I think that may be forcing the mode a bit too much. I've put the new patch inline at the bottom of this message. Please ignore the attached one.

I feel my original explanation of this new feature/bug fix was a bit inadequate, so to see the difference from the current version consider the following:

  1. The editor is in 'div' mode.
  1. The starting html of the editor is preset to the following:
    <p>This is some <strong>sample text</strong>. You are using <a href="">FCKeditor</a>.</p>
    <p>A little more text</p>
    <p>And a bit more.</p>
  2. Whilst inside one of the paragraphs, you hit enter. If you are in the middle of the paragraph, it is simply split in two with both options. But if you are at the beginning or end, the behaviour differs:

Behaviour with patch (and option enabled) - a new <div> is inserted before/after paragraph as appropriate.

Behaviour without patch (or option disabled) - a new <p> is inserted before/after paragraph as appropriate.

Updated patch:

  • classes/fckenterkey.js

    479479                                // If is a header tag, or we are in a Shift+Enter (#77),
    480480                                // create a new block element (later in the code).
    481                                 if ( !this._HasShift && !(/^H[1-6]$/).test( sPreviousBlockTag ) )
     481                                if ( !this._HasShift && !(/^H[1-6]$/).test( sPreviousBlockTag ) && ( !FCKEditor.ForceEnterMode || sPreviousBlockTag == 'LI' ) )
    482482                                {
    483483                                        // Otherwise, duplicate the previous block.
    484484                                        eNewBlock = FCKDomTools.CloneElement( ePreviousBlock ) ;
    485485                                }
    486486                        }
    487                         else if ( eNextBlock )
     487                        else if ( eNextBlock && !FCKEditor.ForceEnterMode )
    488488                                eNewBlock = FCKDomTools.CloneElement( eNextBlock ) ;
    490490                        if ( !eNewBlock )

comment:2 Changed 15 years ago by Neil Jenkins

Keywords: HasPatch added

Changed 15 years ago by Wojciech Olchawa

Attachment: userpatch_2403.patch added

comment:3 Changed 15 years ago by Wojciech Olchawa

Keywords: Confirmed added
Summary: When in div mode inside a <p>, a new <p> is created on enterEnforce EnterMode
Version: SVN

I've just added your changes to a patch. It will be easier to check the patch that way.

Changed 15 years ago by robmueller

Attachment: forceenter.patch added

Updated patch

comment:4 Changed 15 years ago by robmueller

Cc: robmueller added

I've updated the patch with the following changes.

  1. It's checking FCKConfig for the option, not the incorrect FCKEditor
  1. If hit Enter in a block and the block you're in is the same as the EnterMode block tag to create, then it clones the current block tag instead of creating a new one.

The main reason for this is if you set the justification on a block (eg. style="text-justification: right"), or direction (eg dir="rtl"), then that should be cloned to the next block/line when you hit Enter even if ForceEnterMode is on

comment:5 Changed 13 years ago by Garry Yao

This's fixed in v3 with #5302 based on neilj and robmueller's contribution.

comment:6 Changed 11 years ago by Jakub Ś

Version: SVN (FCKeditor) - Retired3.0

This's fixed in v3 with #5302 based on neilj and robmueller's contribution.

This doesn't seem to be fixed neither in CKEditor 3.x or 4.x

To reproduce:

  1. Set enter mode to DIV or P (BR works)
  2. Paste the below code and switch to wysiwyg
  3. Put cursor at the end of line 1, press enter couple of times and do the same for line 2.

Result: Enter behaviour does not respect enter mode. Tags are continued.


comment:7 Changed 11 years ago by Jakub Ś

Another issue:

  1. Set enter mode to Div
  2. Paste following source <div><p>line1</p></div>
  3. Put cusor at the end of line one and press enter

Result: Paragrpahs instead of divs are inserted.

comment:8 Changed 11 years ago by Jakub Ś

Resolution: fixed
Status: confirmedclosed

It seems that this really has been fixed in CKEditor. All that needs to be done is setting

config.forceEnterMode = true;

in config.js

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