Opened 10 years ago

Last modified 10 years ago

#12314 pending Bug

Entermode inconsistencies

Reported by: Dinu Owned by:
Priority: Normal Milestone:
Component: General Version:
Keywords: Cc:

Description

I'm using inline mode, enterMode : CKEDITOR.ENTER_DIV

1) Slap a heap of divs into the editor 2) Hit enter anywhere, a new div is created (is this by design?) 3) Ctrl-A, Del 4) Use source button to verify editor is indeed "empty" 5) Use blocks plugin to verify editor is not actually empty, but has a dummy div holder 6) Hit Enter, divs are still created 7) Use source to set <p></p> for content 8) Hit Enter, <p>s are created now

Problems: 1) Is the enter-in-div=div by design? 2) There should be a way to go back to <p> mode between divs 3) The dummy container created for an empty editor should fall back to <p> if editor is indeed empty

Change History (5)

comment:1 Changed 10 years ago by Dinu

Rectification: using ENTER_P; I pasted wrongly from another sample.

comment:2 Changed 10 years ago by Piotrek Koszuliński

Status: newpending
  1. Enter keeps the current block type (div or p) by design. I don't know the exact reasons, but I presume that it depends on a case whether it makes sense, so there's no perfect solution. You may have content in which in one section divs are used and in second paragraphs - enter should keep the current block in both of them.
  2. Therefore, there's an option config.forceEnterMode which will do what you want.
  3. After ctrl+a, delete indeed <div> is left. I think that this may be considered as a bug, because e.g. after switching to source and back there's <p>. On the other hand, there's no way to distinguish between "select all" and "select contents of this single line" and it may be considered a bug as well if in the second case <div> will be lost on delete. I can extract this scenario into separate ticket, but in such case, when a bugfix may create new bug, we will rather not work on any changes.

comment:3 Changed 10 years ago by Piotrek Koszuliński

Version: 4.4.3

comment:4 Changed 10 years ago by Dinu

For 1 and 2 - thanks, it makes sense. It would be interesting to consider the Office way though: In Office, a chain of containers (styled blocks, lists, etc) is exited by created 2 consecutive empty blocks (pressing CR twice). So it would be interesting if two consecutive empty containers would be replaced by an enterMode container. However, I realize there is quite a difficulty implementing the semantics of an "empty container" since plugins may alter what would otherwise appear as empty containers for various semantics.

For 3, I think there is a way to tell if the unique instance container is a dummy container, since it's not shown in source view. So the question is not detecting Ctrl-A/Del, or affecting containers on any regular operation, just enforcing that the dummy container (that I assume is instance and not block related) respects enterMode?

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

For 3, I think there is a way to tell if the unique instance container is a dummy container, since it's not shown in source view. So the question is not detecting Ctrl-A/Del, or affecting containers on any regular operation, just enforcing that the dummy container (that I assume is instance and not block related) respects enterMode?

Well... it does - https://github.com/ckeditor/ckeditor-dev/blob/master/core/editable.js#L944 So if you end up with div in enterP this means that this div is there after pressing delete which is handled by browsers, not by editor. That's why I'm saying that we would have to handle backspace after CTRL+A manually and that it's tricky.

I'm testing like that:

  1. Default settings. Loaded: <div>foo</div>.
  2. CTRL+A, backspace. You can see "p" in elements path.
  1. Default settings. Loaded <div>foo</div><div>bar</div>.
  2. CTRL+A, backspace. You can see "div" in elements path.

These are results from Chrome, which as you can see is confused. Perhaps FF and IE handle this differently.

Last edited 10 years ago by Piotrek Koszuliński (previous) (diff)
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