Problem description: Selecting text then typing over it uses the formatting from the preceding (to the left) text, rather than maintaining the formatting of the text that is being replaced. Steps to reproduce: 1. In a document with a line of normal text followed by a some bold type text. 2. Make a selection from the start of the bold type text (where normal type is to the left of it and bold is to the right) to some point within the bold text but not up to the end of it. 3. Type in some new text to replace that which was selected. Current behaviour: The new text is not bold, but has the same format of the existing text to the left of it. Expected behaviour: The new text maintains the formatting of the text that it is replacing. Operating System: Windows 7 Version: 4.2.2.1 release
Confirmed in Linux Mint in 3.3.0, 4.2.4 and 4.3 beta. Steps: 1. type 'abcdefg' 2. press Ctrl+B 3. type 'hijklmn' 4. highlight 'hijk' 5. type any number of characters 6. characters typed arent bold
** 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.3 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-06-08
Repro. Win 7 Pro 64-bit Version: 5.1.0.0.alpha1+ Build ID: 3ecef8cedb215e49237a11607197edc91639bfcd TinderBox: Win-x86@62-merge-TDF, Branch:MASTER, Time: 2015-06-19_23:16:58 Locale: fi-FI (fi_FI)
*** Bug 95312 has been marked as a duplicate of this bug. ***
** 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.6 or 5.2.3 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-20161108
*** Bug 112961 has been marked as a duplicate of this bug. ***
Phil Krylov committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/6abed0ea006f3616e40faf2ae782cf64f8ac2914%5E%21 tdf#79717 save/restore character format on selection overwrite It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Phil: I verify the fix. Should this be set to resolved? Arch Linux 64-bit Version: 6.3.0.0.alpha0+ Build ID: 0c7009e751a5c8b3c5f73ac42fad5b4954206fc1 CPU threads: 8; OS: Linux 5.0; UI render: default; VCL: gtk3; Locale: fi-FI (fi_FI.UTF-8); UI-Language: en-US Calc: threaded Built on 17 March 2019
(In reply to Buovjaga from comment #8) > Phil: I verify the fix. Should this be set to resolved? The issue actually seems to be somewhat bigger. First, it also applies not only to direct formatting, but also to character styles. For this I've posted a simple extension of the accepted patch, which is now on review queue at https://gerrit.libreoffice.org/69323 . Then, these patches do fix the problem with direct user input, but do not seem to fix the same problem appearing when replacing text via UNO API (with portion/cursor setString method) or from a spelling suggestion context menu. I am going to further investigate this problem when time permits; probably separate issue numbers should be used (I have now found bug 51423, bug 99786, bug 104137 which probably should be marked duplicates of 51423; but found no filed issue for the UNO API behavior) although they are all clearly related. I've also met this behaviour with Find&Replace, but that seems to be fixed recently.
Ok, thanks a lot! If you get stuck, feel free to email the dev list for assistance.
Phil Krylov committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/+/04bd1925706360414438b814046b543c5e317d0a%5E%21 tdf#79717 save/restore character style on selection overwrite It will be available in 6.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
A polite ping to Phil Krylov: Is this bug fixed? if so, could you please close it as RESOLVED FIXED ? Otherwise, Could you please explain what's missing? Thanks
I went looking for a 6.3 RC but there aren't any yet. I'm hesitant to try an alpha build from the https://dev-builds.libreoffice.org/pre-releases (Sorry, I'm probably butting my head in unnecessarily.)
(In reply to Luke Kendall from comment #13) > I went looking for a 6.3 RC but there aren't any yet. > I'm hesitant to try an alpha build from the > https://dev-builds.libreoffice.org/pre-releases > > (Sorry, I'm probably butting my head in unnecessarily.) 6.3 RC is planned to be released the first week of August, 2019. Meanwhile, you can use LibreOffice 6.3 Alpha1 -> https://wiki.documentfoundation.org/QA/GetInvolved#Test_Pre-releases
I can't reproduce the steps in comment 0 and comment 1, so I think this bug is fixed? Tested 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 Phil Krylov, for the several bugs of overwriting/pasting of text and losing of formatting please see meta bug 127250 (Formatting-Text-Diverse) - [META] Text formatting issues when inserting or overwriting.
*** Bug 79364 has been marked as a duplicate of this bug. ***
Xisco Fauli committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/b05955b480fe4d32852e7be8a118d46ca7e6dbfa tdf#79717: sw_uiwriter: Add unittest It will be available in 7.1.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/036d45b602c2f554f9bcc21fecbc3e3ac5b834da tdf#134426 tdf#138873 sw: Revert "tdf#79717 ... It will be available in 7.3.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-7-2": https://git.libreoffice.org/core/commit/49e8691530ea931eeee74fd88727c2451e98a3bd tdf#134426 tdf#138873 sw: Revert "tdf#79717 ... It will be available in 7.2.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Justin Luth committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/08ede5d51a33f83ededee8a03c10f9bb8244690e tdf#134426 tdf#138873 sw: Revert "tdf#79717 ... It will be available in 7.1.7. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Previous attempt was reverted because it was spamming direct formatting.
Commit 0c3b89da7cde9866bf3174a6276736c76efb8356 could have a logic useful to fix this. Note that after commit 17b39d150fce188f653632a3467891157375a1c6, this bug became worse, because now following steps in comment 1, but selecting 'hijklmn' in step 4, would also misbehave, unlike previously.