Bug 62325 - EDITING: Deleting selected text leaves unexpected font under cursor
Summary: EDITING: Deleting selected text leaves unexpected font under cursor
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
(earliest affected) release
Hardware: All All
: medium normal
Assignee: Not Assigned
: 132894 136168 (view as bug list)
Depends on:
Blocks: Formatting-Text-Diverse
  Show dependency treegraph
Reported: 2013-03-14 08:45 UTC by Matthew Francis
Modified: 2022-09-18 04:09 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:
Regression By:

Example of unexpected font after deletion (8.73 KB, application/vnd.oasis.opendocument.text)
2013-03-14 08:45 UTC, Matthew Francis
Example file (8.73 KB, application/vnd.oasis.opendocument.text)
2020-09-17 07:25 UTC, Telesto
Example file (8.73 KB, application/vnd.oasis.opendocument.text)
2020-09-17 07:27 UTC, Telesto

Note You need to log in before you can comment on or make changes to this bug.
Description Matthew Francis 2013-03-14 08:45:04 UTC
Created attachment 76513 [details]
Example of unexpected font after deletion

When deleting selected text, the font at the end, rather than the start, of the selection is left under the cursor afterwards. This is unexpected.

For example,

If I type "January 1st, 2013", "st" is autocorrected to superscript
Then, if I change my mind, select "1st", delete it, and type "2nd" instead, the result is that the entire text "2nd" is superscripted (not just the "nd")
Comment 1 Tim Lloyd 2013-03-15 01:36:20 UTC
Problem recreated on Windows 7 (LO 4.0.03) and Fedora 18 (LO

Enter the date as described
Move the cursor to the left of the number field (ie. 1st) and delete
any subsequent text entered from this point is superscripted (based on the last character deleted?)
Comment 2 QA Administrators 2015-04-19 03:20:15 UTC Comment hidden (obsolete)
Comment 3 Tim Lloyd 2015-04-19 04:04:38 UTC
Same behaviour. Still present under Fedora 22

Build ID: e7ca29d0b2eaf40dc32b53196282350cc75ed3a0
TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-04-14_04:33:14
Locale: en_AU


Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6
Locale: en_AU
Comment 4 Gordo 2015-06-13 12:44:44 UTC
In certain instances it is possible to get the correct outcome when deleting a number and ordinal indicator and typing in new text.

1. New Text Document.
2. Type “This is the 1st test.” and Enter.
3. Double click on “1st” and Delete.
4. Type “2nd” and Space and delete extra space.
The “2” is normal and the “nd” is in superscript.

Sometimes after the text has been deleted, the superscript icon in the toolbar is on, but if you type something anyway it will be normal.  If you go back and try the steps again with what was already changed then it will not work.  Also, typing over the selection does not work.  If the ordinal number is at the end of a paragraph then it will not work (with no period).  If there is more than one in the same paragraph then it will only work on one of them (This is the 1st time the 2nd has been tested).

Opening a document and using this method on existing numbers and ordinal indicators does not work but typing new text in, selecting it, deleting it, and replacing it, does work.  The only way to change existing documents is to:
1. Select number and ordinal indicator.
2. Ctrl + m.
3. a. Delete or
   b. Type over selection.
4. a. Type intended text or
   b. Enter space.
1. Select number and ordinal indicator and space.
2. a. Delete or
   b. Type over selection.
3. a. Type intended text or
   b. Enter space.

With option A you need to enter a space after it in order for it to auto-correct.  This leaves you with an extra space that needs to be deleted.  So...option B.

I thought for the times that it does work, when deleting a selection there is a check for a normal positioned character at the beginning and a superscript character at the end and post-deletion the character position is defaulted to normal (the selection may cover more than just the number and ordinal indicator so checking for one digit followed by characters with superscript would not be sufficient).  I also tested manually applied superscript as ordinal numbers and superscript between spaces and selecting and deleting did not revert to normal.

Is it possible to auto-correct to a field that holds the ordinal indicator so that typing after it or deleting it would not result in superscript text.  Shame there is no Unicode for the characters.

Added bug 70554 to see also.

Windows Vista 64
Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16

Build ID: 5fc0cbbc1254223fedf0f78c5e7539219b228697
TinderBox: Win-x86@39, Branch:master, Time: 2015-06-11_04:30:51
Comment 5 QA Administrators 2016-09-20 10:00:49 UTC Comment hidden (obsolete)
Comment 6 Mike 2017-12-07 17:50:47 UTC
Issue still there

Version: (x64)
Build ID: 1d8cb97fea57b81a1ab151b88c2180e646bd401b
CPU threads: 4; OS: Windows 10.0; UI render: GL; 
TinderBox: Win-x86_64@42, Branch:master, Time: 2017-12-07_02:07:17
Locale: de-DE (de_DE); Calc: CL
Comment 7 Thomas Lendo 2018-10-03 20:48:42 UTC
Maybe the same root cause as in bug 107857.
Comment 8 QA Administrators 2019-10-04 03:06:14 UTC Comment hidden (obsolete)
Comment 9 Thomas Lendo 2019-10-12 19:46:20 UTC
Still repro with Version: (x64)
Build-ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c
CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win
Comment 10 Thomas Lendo 2020-08-24 19:30:12 UTC
Can't reproduce this issue with
Build ID: a06a83b29a9da770787bffe416b138102aa12531
CPU threads: 2; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: de-AT (de_AT.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-08-24_01:03:26
Calc: CL

Can anybody confirm that too?
Comment 11 Thomas Lendo 2020-08-25 09:14:03 UTC
Don't repro with
Version: (x64)
Build ID: 8700bace8c0714d853f5df6918ab9c8bb3d81f77
CPU threads: 12; OS: Windows 10.0 Build 18363; UI render: Skia/Vulkan; VCL: win
Locale: de-AT (de_AT); UI: en-US
build from August 21, 2020

Also fixed with patch for bug 135721?
Comment 12 Telesto 2020-08-25 09:48:10 UTC
Not totally sure if this is fixed
A) Select "1st" in the second line of the sample document (double clicking or draging with mouse or with or with CTRL+SHIFT ARROW LEFT or RIGHT depending on choice

Or Select "1st". Press backspace & start typing. No issue when simply overwriting (typing without backspace)

However, mostly someone starts explaining this being the way it's implemented.
Comment 13 Telesto 2020-08-25 09:53:19 UTC
This is about cursor & formatting (see comment 12). I see this as a problem (bug), but I'm mostly wrong about that with this kind of issues. So would love you're assessment
Comment 14 Mike Kaganski 2020-08-25 10:05:46 UTC
(In reply to Telesto from comment #13)

IMO this is completely UX-decided issue (so it's possible to do both ways - or even multiple ways: always using leftmost point of selection? always using rightmost point? taking into account selection direction? and maybe RTL/LTR text, too? ... , and depends just on a decision taken). No opinion on the "correct" way of doing this from me.
Comment 15 Heiko Tietze 2020-09-10 08:39:02 UTC
The applied formatting (whether direct or per character style) continues in the writing direction and superscript or font color remains until it is unset. If you delete a character you still expect the formatting, eg. when correcting the typo in 1^sd. => NAB (leave it to others to resolve the ticket)

You might argue that white space should stop the formatting. In some situations it could be helpful, of course, but in other not. Consider the situation you want to write in big red letter "Lorem ipsum dolor est" and you have to set the formatting again after each space. It's much easier to switch off at the end.
Comment 16 Telesto 2020-09-15 21:56:20 UTC
*** Bug 132894 has been marked as a duplicate of this bug. ***
Comment 17 Telesto 2020-09-16 15:26:27 UTC
*** Bug 136168 has been marked as a duplicate of this bug. ***
Comment 18 Telesto 2020-09-17 07:25:59 UTC
Created attachment 165602 [details]
Example file

1. Place cursor between xxxx and cc
2. Type something expected
3. Press Delete single time.. -> Bold. 
4. Move arrow left & press backspace -> bold
5. Select the line &  Backspace -> Bold

6. Example B (same as above different context)
7. Go at the end of the xxxx and press delete -> Bold
8. Press CTRL+A Backspace & start typing (bold)

The behavior is consistent; not a big fan however.
Comment 19 Telesto 2020-09-17 07:27:40 UTC
Created attachment 165603 [details]
Example file
Comment 20 QA Administrators 2022-09-18 04:09:35 UTC
Dear Matthew Francis,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://web.libera.chat/?settings=#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team