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")
Problem recreated on Windows 7 (LO 4.0.03) and Fedora 18 (LO 4.0.1.2). 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?)
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (4.4.1 or later) https://www.libreoffice.org/download/ *If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior *If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for your help! -- The LibreOffice QA Team This NEW Message was generated on: 2015-04-18
Same behaviour. Still present under Fedora 22 Version: 4.5.0.0.alpha0+ Build ID: e7ca29d0b2eaf40dc32b53196282350cc75ed3a0 TinderBox: Linux-rpm_deb-x86_64@46-TDF, Branch:master, Time: 2015-04-14_04:33:14 Locale: en_AU and Version: 4.4.2.2 Build ID: c4c7d32d0d49397cad38d62472b0bc8acff48dd6 Locale: en_AU
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. Result: 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: A) 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. B) 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 Version: 4.4.3.2 Build ID: 88805f81e9fe61362df02b9941de8e38a9b5fd16 Version: 5.1.0.0.alpha1+ Build ID: 5fc0cbbc1254223fedf0f78c5e7539219b228697 TinderBox: Win-x86@39, Branch:master, Time: 2015-06-11_04:30:51
** Please read this message in its entirety before responding ** 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 on a currently supported version of LibreOffice (5.1.5 or 5.2.1 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System 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) http://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: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20160920
Issue still there Version: 6.1.0.0.alpha0+ (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
Maybe the same root cause as in bug 107857.
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 http://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://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug
Still repro with Version: 6.3.2.2 (x64) Build-ID: 98b30e735bda24bc04ab42594c85f7fd8be07b9c CPU-Threads: 4; BS: Windows 10.0; UI-Render: GL; VCL: win
Can't reproduce this issue with Version: 7.1.0.0.alpha0+ 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?
Don't repro with Version: 7.1.0.0.alpha0+ (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?
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 B) CTRL+X C) CTRL+V 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.
@Mike 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
(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.
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.
*** Bug 132894 has been marked as a duplicate of this bug. ***
*** Bug 136168 has been marked as a duplicate of this bug. ***
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.
Created attachment 165603 [details] Example file
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 MassPing-UntouchedBug