Opened 14 years ago

Closed 14 years ago

Last modified 14 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 Minnekanti Owned by: Garry Yao
Priority: Normal Milestone: CKEditor 3.3
Component: Core : Lists Version: 3.2
Keywords: IBM Discussion Confirmed Review+ Cc: joek, Damian

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 14 years ago.
5402_2.patch (1.5 KB) - added by Garry Yao 14 years ago.

Download all attachments as: .zip

Change History (14)

comment:1 Changed 14 years ago by Garry Yao

Keywords: Discussion added

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

Changed 14 years ago by Garry Yao

Attachment: 5402.patch added

comment:2 Changed 14 years ago by Garry Yao

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

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

comment:3 Changed 14 years ago by Alfonso Martínez de Lizarrondo

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 14 years ago by Garry Yao

Attachment: 5402_2.patch added

comment:4 Changed 14 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 14 years ago by Alfonso Martínez de Lizarrondo

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 14 years ago by Garry Yao

Resolution: fixed
Status: assignedclosed

Fixed with [5423].

comment:7 Changed 14 years ago by Satya Minnekanti

Resolution: fixed
Status: closedreopened

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 14 years ago by Garry Yao

Resolution: fixed
Status: reopenedclosed

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

comment:9 Changed 14 years ago by Satya Minnekanti

Resolution: fixed
Status: closedreopened

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 14 years ago by Garry Yao

Resolution: fixed
Status: reopenedclosed

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

comment:11 Changed 14 years ago by Damian

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 14 years ago by Alfonso Martínez de Lizarrondo

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 – 2022, CKSource sp. z o.o. sp.k. All rights reserved. | Terms of use | Privacy policy