Opened 5 years ago

Last modified 3 years ago

#12634 confirmed Bug

Impossible to place caret in an empty inline style that existed in an empty block

Reported by: Piotrek Koszuliński Owned by:
Priority: Normal Milestone:
Component: Core : Selection Version: 3.0
Keywords: IBM Cc: satya_minnekanti@…

Description (last modified by Piotrek Koszuliński)

  1. Open any sample.
  2. Clean the contents.
  3. Press the bold button and type something.
  4. Press enter multiple times. Notice that the bold style is preserved.
  5. Start pressing up arrow or clicking in the empty paragraphs.
  6. Notice that bold is gone.
  7. Check the DOM - strong elements are still there.

There are two solutions possible:

  1. Put bogus <br> inside empty inline elements. Then, I think that browsers will place the caret inside empty blocks by themselves.
  2. Handle this on keyup and mouseup events. Check whether collapsed selection was placed next to empty inline element in an empty line and fix the selection.

BTW. Note that pressing the bold button again after navigating to the empty line will create another strong tag. This is due to #12633.

Change History (15)

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

Description: modified (diff)

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

Summary: Impossible to place caret in empty inline style that existed in an empty blockImpossible to place caret in an empty inline style that existed in an empty block

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

We could also fix this issue #3509 on Firefox if we handled also non-empty lines.

comment:4 Changed 4 years ago by Jakub Ś

#12900 was marked as duplicate.

comment:5 Changed 4 years ago by Jakub Ś

Cc: satya_minnekanti@… added
Keywords: IBM added
Status: newconfirmed
Version: 3.0

#13082 was marked as duplicate.

comment:6 Changed 4 years ago by Jakub Ś

#13104 was marked as duplicate.

comment:7 Changed 4 years ago by Jakub Ś

#13290 was marked as duplicate.

comment:8 Changed 4 years ago by ganbin

Is this bug will be consider by the team? Or this should be consider as a standard behavior? Could be nice to know if the team will be involve to solve this problem.

comment:9 Changed 4 years ago by Piotrek Koszuliński

The current behaviour isn't perfect. It's acceptable, but it could be better if we fixed this issue. However, it's not a cheap thing to have. So taking into account that the current behaviour is acceptable and the costs of changing it, we do not plan to work on this issue unless:

  • someone funds it,
  • more developers upvote it,
  • we have no other important tickets to work on (well... unlikely :)).

comment:10 Changed 4 years ago by Danny

+1

Still having this issue in version 4.4.6. Quite a frustrating problem for users.

comment:11 in reply to:  9 Changed 4 years ago by Danny

Hey Reinmar, You mentioned this bug could get fixed if someone funds it. How could I go about getting an estimated timeline/cost?

Thanks!

Replying to Reinmar:

The current behaviour isn't perfect. It's acceptable, but it could be better if we fixed this issue. However, it's not a cheap thing to have. So taking into account that the current behaviour is acceptable and the costs of changing it, we do not plan to work on this issue unless:

  • someone funds it,
  • more developers upvote it,
  • we have no other important tickets to work on (well... unlikely :)).

comment:12 Changed 4 years ago by Piotrek Koszuliński

How could I go about getting an estimated timeline/cost?

You can use this form: https://cksource.com/contact

comment:13 Changed 4 years ago by Jakub Ś

#14238 was marked as duplicate.

comment:14 Changed 3 years ago by Marek Lewandowski

cc

comment:15 Changed 3 years ago by Jakub Ś

#14773 was marked as duplicate.

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