Opened 10 years ago
Last modified 8 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 )
- Open any sample.
- Clean the contents.
- Press the bold button and type something.
- Press enter multiple times. Notice that the bold style is preserved.
- Start pressing up arrow or clicking in the empty paragraphs.
- Notice that bold is gone.
- Check the DOM - strong elements are still there.
There are two solutions possible:
- Put bogus <br> inside empty inline elements. Then, I think that browsers will place the caret inside empty blocks by themselves.
- 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 10 years ago by
| Description: | modified (diff) |
|---|
comment:2 Changed 10 years ago by
| Summary: | Impossible to place caret in empty inline style that existed in an empty block → Impossible to place caret in an empty inline style that existed in an empty block |
|---|
comment:3 Changed 10 years ago by
comment:5 Changed 10 years ago by
| Cc: | satya_minnekanti@… added |
|---|---|
| Keywords: | IBM added |
| Status: | new → confirmed |
| Version: | → 3.0 |
#13082 was marked as duplicate.
comment:8 Changed 9 years ago by
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 follow-up: 11 Changed 9 years ago by
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 9 years ago by
+1
Still having this issue in version 4.4.6. Quite a frustrating problem for users.
comment:11 Changed 9 years ago by
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 9 years ago by
How could I go about getting an estimated timeline/cost?
You can use this form: https://cksource.com/contact
We could also fix this issue #3509 on Firefox if we handled also non-empty lines.