Description: I discovered this while investigating bug 93495 comment 4. Pressing the tab key at the beginning of a heading paragraph sometimes changes the heading level as expected, and other times it indents the paragraph. Furthermore, when it indents the paragraph it changes the properties of the style rather than adding a tab stop or direct formatting, and these changes are applied to other heading styles as well. Even this can be inconsistent -- sometimes the other styles are unaffected if they have already been modified from their defaults. Clearly something weird is going on. This is all in contrast to the "increase indent" toolbar button, which consistently changes the heading level as expected. Further details: - As far as I can tell, the strange behavior of the tab key occurs only for the first instance of a heading paragraph, regardless of the heading level. - The Shift-Tab key combo does nothing in these cases. Steps to Reproduce: 1. Press tab at the beginning of a heading paragraph. Actual Results: Indentation of the relevant heading paragraph style, and other heading paragraph styles, is changed. Expected Results: The heading level of the current paragraph is increased. Reproducible: Always User Profile Reset: No Additional Info: The indentation properties of the relevant heading style, and perhaps other heading styles, are changed if the tab key is pressed at the beginning of the first occurrence of a heading paragraph.
Created attachment 146008 [details] Document for experimenting with the tab key Delete, reorder, or reset the style of the headings to see the the main effect occurs only for the first heading paragraph, regardless of heading level. To show how all styles are sometimes not affected, modify the indentation properties of one of the styles and repeat the experiment.
I can reproduce the bug. Version: 6.0.6.2 Build ID: 0c292870b25a325b5ed35f6b45599d2ea4458e77 CPU threads: 2; OS: Windows 6.1; UI render: default; Locale: en-US (en_US); Calc: group
I can reproduce the bug. Version: 6.3.0.0.alpha0+ (x64) Build ID: 0f25a3c36f27fd51453b9a9115f236b83c143684 CPU threads: 8; OS: Windows 10.0; UI render: GL; VCL: win; TinderBox: Win-x86_64@42, Branch:master, Time: 2018-11-27_20:06:55 Locale: zh-TW (zh_TW); UI-Language: en-US Calc: threaded
I can reproduce the bug. 版本：6.0.7.3 (x64) 組建 ID：dc89aa7a9eabfd848af146d5086077aeed2ae4a5 CPU 執行緒：8; OS：Windows 10.0; UI 算繪：GL; 語言地區：zh-TW (zh_TW); Calc: CL
QA please decide what to do taking bug 93495 into account.
(In reply to Heiko Tietze from comment #5) > QA please decide what to do taking bug 93495 into account. Heiko, I changed status tio NEW, because - as far as I can understand from bug 93495 - it is the desired result, that tab key should change the heading level. So I don't see, why this bug report is not in line with bug 93495.
Also reproduced in LibreOffice 3.3.0 OOO330m19 (Build:6) tag libreoffice-3.3.0.4
Dear Kenneth Hanson, 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
Behavior is somewhat different in v7.4.2.3, but still mysterious. - Tab at the beginning of line inserts a tab stop - Shift+Tab decreases the heading level for the current paragraph only - Ctrl+Tab increases the indent (different from both the above) for every heading in the document
Some recent changes implemented for bug 146762, see discussion and decision there.
(In reply to Kenneth Hanson from comment #9) > Behavior is somewhat different in v7.4.2.3, but still mysterious. > - Tab at the beginning of line inserts a tab stop See bug 152594 > - Shift+Tab decreases the heading level for the current paragraph only > - Ctrl+Tab increases the indent (different from both the above) for every > heading in the document Appears to correspond to expected design (per bug 146762) see: https://help.libreoffice.org/7.4/en-US/text/swriter/04/01020000.html#bm_id3150396
@Kenneth Hanson maybe you can test the attachments at bug 152594, comment 4 and bug 152594, comment 5. Possibly this ticket is a duplicate of bug 152594.
I'd agree this is at this point the original issue was fixed in bug 146762, remaining problem is tracked in bug 152594 *** This bug has been marked as a duplicate of bug 146762 ***