Ticket #5026 (confirmed Bug)

Opened 5 years ago

Last modified 2 years ago

Style detection/removal incorrect in FireFox

Reported by: n8behavior Owned by:
Priority: Normal Milestone:
Component: Core : Styles Version: 3.1
Keywords: Cc: mike@…

Description

Recreate Bug

Use Firefox (I tested on both Windows FF 3.5.7 and Linux FF 3.5.5) and the online demo and perform the following steps.

Setup

  1. Click in the editor and remove all content i.e. <CTRL> + <A> then <BKSP>
  2. Type or paste in: foo bar baz
  3. Double-click bar and make it bold. Notice That FF on Linux selects only the word bar on double-click. Chrome and IE8 on Windows select the word plus one trailing space, which also gets the bold style.

Test 1

  1. Place the cursor anywhere in the word baz then move left with the arrow key to the end of the word bar. Notice that the B button is NOT active and the status bar displays only body p.
  2. Use the arrow keys to move left then right one character, returning to the same position. Notice that the B button is active and the status bar displays body p strong.
  3. Use the arrow keys to move right then left one character, again returning to the same position. Notice that the B button is NOT active and the status bar displays only body p.

This inconsistency is confusing my users and is likely related to the odd behave I will describe next.

Test 2

  1. Again, place the cursor to anywhere in the word baz then move left with the arrow key to the end of the word bar.
  2. Backspace to the end of the word foo, completely deleting the word bar and the space between foo and bar.
  3. Type <space>bar to replace the original text. Notice that the text is bold again. But rather than a STRONG tag we have a SPAN with inline style.

Unless you delete both foo and bar you cannot get rid of the littered inline style. These tests exhibit the same behavior using italic and underline, and indeed my own custom styles. This behavior is not exhibited using Chrome nor IE8. I have tested this in 3.01, 3.02 and 3.1. All exhibit the bug in FF only.

Change History

comment:1 Changed 5 years ago by fredck

  • Keywords Confirmed added

I can confirm both things in Firefox, but they are completely different. We should have two different tickets. But let's analyse them first.

Test 1 (CantFix): This is a Firefox feature. That's the way it handles cursor navigation so it makes it possible to position inside and outside elements. In this way the user can decide whether to continue typing in bold or to not have it instead. This is something out of our control, so we can't change this behavior. Some users will find it useful though.

Test 2 (Confirmed): This is definitely an issue, and certainly a Firefox bug. Let's see if this is fixable.

comment:2 Changed 4 years ago by fredck

  • Milestone CKEditor 3.x deleted

Milestone CKEditor 3.x deleted

comment:3 Changed 2 years ago by j.swiderski

Test 1 - dup of #8195

Test 2 - Can be reproduced in CKEditor 4.x (v4)

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