Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#5402 closed Bug (fixed)

if we apply Pre-Formatted formatting to a list item in an Ordered/Unordered list we can't create new list items & also we can't come out of the list

Reported by: satya Owned by: garry.yao
Priority: Normal Milestone: CKEditor 3.3
Component: Core : Lists Version: 3.2
Keywords: IBM Discussion Confirmed Review+ Cc: joek, damo

Description

To reproduce the defect

  1. Open Ajax sample
  1. Click on Numbers icon to start a Numbered list.
  1. Type some text after the first number in the list.
  1. Select the text in list item and apply Pre-Formatted formatting.
  1. See that Pre-Formatted formatting is applied to the list item.
  1. Now press Enter

Expected Result

See that next number comes up in the ordered list and when we press the Enter for the second time,the cursor should come out of the Ordered list and a new empty Paragraph should open

Actual Result

The Next Number in the ordered list do not comes up and when we Press Enter any number of times we can't come out of the list.

Same behaviour is also happening in the case of Bullets.

Attachments (2)

5402.patch (5.5 KB) - added by garry.yao 6 years ago.
5402_2.patch (1.5 KB) - added by garry.yao 6 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 6 years ago by garry.yao

  • Keywords Discussion added

Does anyone have suggestion of the best way to deal with this case?

Changed 6 years ago by garry.yao

comment:2 Changed 6 years ago by garry.yao

  • Keywords Confirmed Review? added
  • Owner set to garry.yao
  • Status changed from new to assigned

Proposing of an additional Ctrl-Shift-Enter mode for existing from any block.

comment:3 Changed 6 years ago by alfonsoml

  • Keywords Review- added; Review? removed

I think that no one except those that read this ticket will know about Ctrl+Shift+Enter, most of the people ignore Shift+Enter, so another combination wouldn't help too much.

The main problem is getting out of PRE, the list is just a little distraction, but in general it should be easier to get out of that condition. In a little test it seems that Shift+Enter in PRE doesn't do anything special, so we could reuse that combination to end the PRE and generate a P. Then the user can press enter again to end the LI

Another additional method to help users would be to make the Format combo not change the whole PRE but just end it if the user selects Normal at the end of the block. In general, trying to change the Format at the end of one block should end that block and create a new one instead of changing the whole block (if the selection is collapsed and at the end of the block)

Changed 6 years ago by garry.yao

comment:4 Changed 6 years ago by garry.yao

  • Keywords Review? added; Review- removed

Utilize shiftEnter was my initial thought, we could provide alternative approach later, but I doubt the idea that Format combo behavior variously because of the cursor position.

comment:5 Changed 6 years ago by alfonsoml

  • Keywords Review+ added; Review? removed

Yes, my proposal was to fix first this ticket and also study other options about how users expect the editor to work. I've filed #5600 to discuss that option.

comment:6 Changed 6 years ago by garry.yao

  • Resolution set to fixed
  • Status changed from assigned to closed

Fixed with [5423].

comment:7 Changed 6 years ago by satya

  • Resolution fixed deleted
  • Status changed from closed to reopened

This is not properly fixed.

After applying 'pre' formatting to a list item and when i Press Enter it should create a new list item in the Order list and when the user press Enter for the second time then the cursor should come out of the list.

But at the moment when the user press Enter for the first time the cursor is coming out of the list.

comment:8 Changed 6 years ago by garry.yao

  • Resolution set to fixed
  • Status changed from reopened to closed

WFM, 'shift-Enter' in <pre> behaviors exactly the same as described.

comment:9 Changed 6 years ago by satya

  • Resolution fixed deleted
  • Status changed from closed to reopened

There are 2 Iconsistent issues here with Pre

  1. First--The way Pre behaves is inconsistent from other Formmatings when Pre is applied to a list item.

For eg: when we apply Heading 1 to a list item, the user normally presses Enter to create a new list item and this is the same for all the formatting options, where as when Pre is applied the user has to press Shift+Enter which is inconsistent and also it is not documented any where.

  1. Second--The way Pre behaves is inconsistent from other Formmatings when Pre is applied to Normal Text.

For eg: when we apply Heading 1 to a Normal Text,and when the user press Enter, the formatting is lost and a new paragraph is created & when the user presses Shift+Enter a new line is created with the same formatting, where as with Pre when the user presses Enter no new paragraph is created & when the user press Shift+Enter a new Pre is created instead of a new line.

comment:10 Changed 6 years ago by garry.yao

  • Resolution set to fixed
  • Status changed from reopened to closed

It make sense for enterMode=block, perhaps we can swap the functionality of 'Enter' and 'ShiftEnter' in <pre> in this case?

comment:11 Changed 6 years ago by damo

I agree, <pre> should behave like <p>:

ENTER = breaks out of the <pre>
SHIFT+ENTER = new line break within <pre> This applies to lists also.

Currently, it behaves exactly opposite to <p>, which is confusing.

Do we need a separate defect for this?

comment:12 Changed 6 years ago by alfonsoml

This ticket was about being able to follow a list if PRE was applied in an item.

A change to the general way that PRE works deserves its own ticket so the logic that has led to the current behavior can be tested and verify if it can be improved.

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