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 |
Description
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)
Change History (11)
Changed 15 years ago by
Attachment: | enterKeyPatch.diff added |
---|
comment:1 Changed 15 years ago by
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:
- The editor is in 'div' mode.
- The starting html of the editor is preset to the following:
<p>This is some <strong>sample text</strong>. You are using <a href="http://www.fckeditor.net/">FCKeditor</a>.</p> <p>A little more text</p> <p>And a bit more.</p>
- 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
478 478 479 479 // If is a header tag, or we are in a Shift+Enter (#77), 480 480 // 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' ) ) 482 482 { 483 483 // Otherwise, duplicate the previous block. 484 484 eNewBlock = FCKDomTools.CloneElement( ePreviousBlock ) ; 485 485 } 486 486 } 487 else if ( eNextBlock )487 else if ( eNextBlock && !FCKEditor.ForceEnterMode ) 488 488 eNewBlock = FCKDomTools.CloneElement( eNextBlock ) ; 489 489 490 490 if ( !eNewBlock )
comment:2 Changed 15 years ago by
Keywords: | HasPatch added |
---|
Changed 15 years ago by
Attachment: | userpatch_2403.patch added |
---|
comment:3 Changed 15 years ago by
Keywords: | Confirmed added |
---|---|
Summary: | When in div mode inside a <p>, a new <p> is created on enter → Enforce EnterMode |
Version: | → SVN |
I've just added your changes to a patch. It will be easier to check the patch that way.
comment:4 Changed 15 years ago by
Cc: | robmueller added |
---|
I've updated the patch with the following changes.
- It's checking FCKConfig for the option, not the incorrect FCKEditor
- 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
This's fixed in v3 with #5302 based on neilj and robmueller's contribution.
comment:6 Changed 11 years ago by
Version: | SVN (FCKeditor) - Retired → 3.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:
- Set enter mode to DIV or P (BR works)
- Paste the below code and switch to wysiwyg
<p>line1</p> <div>line2</div>
- 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.
<p>line1</p> <p> </p> <div>line2</div> <div> </div>
comment:7 Changed 11 years ago by
Another issue:
- Set enter mode to Div
- Paste following source
<div><p>line1</p></div>
- 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
Resolution: | → fixed |
---|---|
Status: | confirmed → closed |
It seems that this really has been fixed in CKEditor. All that needs to be done is setting
config.forceEnterMode = true;
in config.js
Patch