Description: 1. In LO Writer version 7.0.4.2 if I start by typing a question and have 3 or more subpoints to make. a. This would be the first point. A TAB character is the first character in this line. b. Everything seems to be working well so far. c. This also seems OK until you push return at the end of this line. c. This is what you get after pushing return at the end of the third line using a TAB character as the first character. Very repeatable. Does not crash but messes up the formatting of that line by removing the TAB character at the beginning of line c. Steps to Reproduce: 1. In LO Writer version 7.0.4.2 if I start by typing a question and have 3 or more subpoints to make. a. This would be the first point. A TAB character is the first character in this line. b. Everything seems to be working well so far. c. This also seems OK until you push return at the end of this line. c. This is what you get after pushing return at the end of the third line using a TAB character as the first character. Very repeatable. Does not crash but messes up the formatting of that line by removing the TAB character at the beginning of line c. Actual Results: 1. In LO Writer version 7.0.4.2 if I start by typing a question and have 3 or more subpoints to make. a. This would be the first point. A TAB character is the first character in this line. b. Everything seems to be working well so far. c. This is what you get after pushing return at the end of the third line using a TAB character as the first character. Expected Results: 1. In LO Writer version 7.0.4.2 if I start by typing a question and have 3 or more subpoints to make. a. This would be the first point. A TAB character is the first character in this line. b. Everything seems to be working well so far. c. This is what I expect after I push return at the end of this line. Reproducible: Always User Profile Reset: Yes Additional Info: It should not delete the TAB character at the beginning of line c. Version: 7.0.4.2 Build ID: dcf040e67528d9187c66b2379df5ea4407429775 CPU threads: 4; OS: Mac OS X 10.13.6; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded
I can't confirm it with Version: 7.1.0.3 (x64) / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL But your steps are not clear to me. For example, I don't know, if you're using a list (style) and a certain paragraph style. So please attach a sample document, as this makes it easier for us to verify the bug. I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' once the requested document is provided. (Please note that the attachment will be public, remove any sensitive information before attaching it)
Created attachment 169833 [details] document that shows the bug 140105 1. This document shows the bug 140105 where TAB characters are removed from the beginning of a line in Writer upon pushing the RETURN key at the end of the third line that starts with a TAB. All of the following lines SHOULD have a TAB at the beginning, but upon pushing RETURN the TAB character is deleted. See below: a. First line with a TAB character. Pushing RETURN will not cause any unforeseen issue. b. Second line with TAB character. No issues here either. c. Third line with a TAB character at the beginning. Pushing RETURN will remove the TAB. d. Fourth line with a TAB at beginning. e. Fifth line with a TAB character. Pushing RETURN will cause no issue f. Sixth line with TAB at beginning. g. Seventh line with TAB character at beginning h. Eight line with a TAB at beginning I. Ninth line with TAB at Beginning j. Tenth line with TAB character at beginning. k. 11th line with TAB l. 12th line with TAB m. 13th line with TAB n. 14th line with TAB m 15th line with TAB o. 16th line with TAB p. 17th line with TAB q. 18th line with TAB r. 19th line with TAB s. 20th line with TAB
I have uploaded a document that shows the bug. I have also confirmed the bug occurs in version 6 of LibreOffice on LINUX on another computer. Daniel Sczygelski laserski@aol.com
Also occurs in old versions of LO on LINUX on another computer. Sample document uploaded.
I can also confirm this issue on v 7.1.1.1 As a bit of clarification, this is not using the bulleted or order list options to create the list formatting for you. The indenting is generated with TABs as mentioned by Dan, and then one of the TABs is automatically removed when adding a new line. This could (at least) be annoying for users that copy text from a text file, and then begin to make changes in LO Writer. Here are the steps I take to reproduce the issue: 1. Use TAB to indent a line and type 'a.' then SPACE, and then some text > a. first line of text 2. Hit ENTER to start a new line 3. Repeat Step 1 to create a second line of text > b. second line of text 4. Hit ENTER to start a new line 5. Repeat Step 1 to create a third line of text > c. third line of text 6. Hit ENTER The result is that a new line is created and the indentation of the third line is removed. a. first line of text b. second line of text c. third line of text Note: If you fix this by going back up a line and re-adding the TAB to before the 'c.' you can then go back down (with ARROW key) to the new line and the 'c. ' line is left alone. But if you add another line ('d. some text') and then hit ENTER, the same thing happens again. However, if you do the same thing AGAIN with a 5th line ('e. some text') it doesn't happen. ADDITIONALLY... The TAB character is removed on the FIRST line when using other list characters '1.' (with decimal), 'I.' (with decimal) and '*' (no decimal). So, for example... 1. Use TAB to indent a line and type '1.' then SPACE, and then some text > 1. first line of text 2. Hit ENTER to start a new line The result is that a new line is created but the indentation of the third line is removed. 1. first line of text I have not seen it happen (yet) with other easily typeable characters (#, $, >) that I imagine someone might use to create a list. I have not yet experimented with other characters that might be copied from another file. Build: 575c5867c4cc13d7ae78f9ce39a54a52ed38c769 OS: Windows 10 (x64)
I can reproduce it now with Version: 7.1.0.3 (x64) / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 4; OS: Windows 10.0 Build 19042; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL Steps to reproduce 1. Open new document (default paragraph style) 2. Press TAB and write "c. " 3. Press Enter Actual result: Tabulation of first line gets lost. Additional information: Also happens with d, i, l, m, v and x. Very similar to bug 127524.
Dear Dan Sczygelski, 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
This bug is still present in 7.5.0.3. It was also present in version 3.3, so I set the version to Inherited From OOo as requested. Version info below: Version: 7.5.0.3 (AARCH64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 10; OS: Mac OS X 13.2.1; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Daniel Sczygelski laserski@aol.com
Can't confirm with Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: de-DE (de_DE); UI: en-GB Calc: CL threaded
Created attachment 188788 [details] How to reproduce bug #140105
Version: 7.5.5.2 (X86_64) / LibreOffice Community Build ID: ca8fe7424262805f223b9a2334bc7181abbcbf5e CPU threads: 8; OS: Mac OS X 11.7.4; UI render: default; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded Bug is still there. For me it happens if you start a paragraph with some numbering character like "1" or "(1)" (but no list format used!) or else and add additional lines (with shift-return) starting with a tab (for indentation). After hitting RETURN at the last line, all the starting (indenting) tabs are removed and replaced with spaces. See the uploaded document to reproduce the bug.
Very very strange. I reproduce the oddities in comment 6 by Dieter: Version: 24.2.0.3 (X86_64) / LibreOffice Community Build ID: da48488a73ddd66ea24cf16bbc4f7b9c08e9bea1 CPU threads: 8; OS: Windows 10.0 Build 22631; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded - - - It looks like there's some sort of: - "Roman Numeral detection" issue going on here. - - - To see it working fine, I did: 1. Press TAB. 2. Type "a. Test." 3. Press ENTER. It stays indented. Same if you tried Step: 2A. Type "b. Test." ... but it's BROKEN if you type in: - c. Test the TAB gets gobbled up! - - - And, just like Dieter wrote: > Also happens with d, i, l, m, v and x. Yes, same exact symptoms here. In Step 2, these a-z letters don't work: - c - d - i - l - m - v - x but all the other letters do. And what do those broken ones have in common? They're all Roman Numerals!