Reproduced.
Version: 26.2.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 620(Build:0)
CPU threads: 8; OS: Windows 11 X86_64 (build 26100); UI render: Skia/Raster; VCL: win
Locale: ja-JP (ja_JP); UI: ja-JP
Calc: CL threaded Jumbo
https://dev-builds.libreoffice.org/daily/master/Win-x86_64@tb103-1-TDF/2025-11-28_04.05.28/


Reverse pattern of Bug 67797…?

From my quick observation, Tools > AutoCorrect > AutoCorrect Options > Options > "Delete spaces and tabs at beginning and end of paragraph" seems to behave incorrectly.
The help page "Delete spaces and tabs at beginning and end of paragraph" states, "To use this option, the Apply Styles option must also be selected". However, it still works even when "Apply Styles" is off.

These conditions are the same as Bug 67797, Comment 19.

bibisected with linux-64-26.2
commit 5bd1efb830400e1394d45f122faf7537e4451f33
author	Samuel Mehrbrodt

tdf#168228 Don't replace styles unconditionally

***
adding CC: Samuel Mehrbrodt
Please, take a look?

I performed a Bibisect and ran it twice; both times it gave me the same results. 

commit 75d131082ce51ed5a898d97bdc2b7a9fe5ddb340 (bundle/master, bundle/HEAD, master)
Date:   Thu May 2 06:08:40 2019 -0700

Only the first one had the issue. I'm not entirely sure I did this correctly.

(In reply to Takenori Yasuda from comment #1)

> From my quick observation, Tools > AutoCorrect > AutoCorrect Options >
> Options > "Delete spaces and tabs at beginning and end of paragraph" seems
> to behave incorrectly.
> The help page "Delete spaces and tabs at beginning and end of paragraph"
> states, "To use this option, the Apply Styles option must also be selected".
> However, it still works even when "Apply Styles" is off.
> 
> These conditions are the same as Bug 67797, Comment 19.

the question is, why is it documented to behave in this way?

my suspicion is that this dependency of one option on another option was not actually intended, and then the existing behaviour was documented in the help content.

i think UX people need to decide what the intended behaviour is.

(In reply to Michael Stahl from comment #4)
> (In reply to Takenori Yasuda from comment #1)
> 
> > From my quick observation, Tools > AutoCorrect > AutoCorrect Options >
> > Options > "Delete spaces and tabs at beginning and end of paragraph" seems
> > to behave incorrectly.
> > The help page "Delete spaces and tabs at beginning and end of paragraph"
> > states, "To use this option, the Apply Styles option must also be selected".
> > However, it still works even when "Apply Styles" is off.
> 
> i think UX people need to decide what the intended behaviour is.

I see no reason to bind the existence of spaces/tabs to a paragraph style. IOW, the current behavior is correct and the documentation wrong.

The OP's issue of disappearing tabs sounds like something that happens to many user (formatting a document with spaces and tabs) - and in an ideal world we somehow tell the user what has happened (for example via infobar).

(In reply to Heiko Tietze from comment #5)
> IOW, the current behavior is correct and the documentation wrong.
Assuming the current behavior (where "Delete spaces and tabs at beginning and end of paragraph" operates independently) is correct, what should the intended behavior actually be when it triggers? The behavior differs across versions:

[Up to 25.8.3]
Before the Bug 67797 fix (all leading/trailing tabs and spaces are removed when the numbered list begins with digits or Roman numerals)

[25.8.4]
All leading/trailing tabs and spaces are removed

[26.2]
After the Bug 67797 fix (Bug 67797, Comment 23?)

[26.2 and later (this report)]
The inverse of Bug 67797 (all leading/trailing tabs and spaces are removed except for numbered lists beginning with digits or Roman numerals)

If the bug described in this report had not occurred, and if the behavior in 25.8.4 had been identical to that of 25.8.3 and earlier, then updating the documentation alone might have been sufficient. However, since multiple differing behaviors now exist across versions, I believe the feature itself should also be corrected.

*** Bug 170059 has been marked as a duplicate of this bug. ***

(In reply to Takenori Yasuda from comment #6)
> However, since multiple differing behaviors now exist across versions,
> I believe the feature itself should also be corrected.

To start with the motivation: a document shall not be formatted with spaces or tabs. We have the automatic correction of (in most cases unintentionally added) tabs or spaces, whether trailing or leading. As a convenience feature we change the level of lists items with tab / shift+tab (see bug 146762); inserting a literal tab is possible with shift+alt+tab.

I struggle a bit with the list of changes and what of these premises have changed. And even if, why should we change the current behavior (given the option allows a different workflow too).

Last but not least I repeat my idea of better feedback. If the OP would have known what causes the tab to "disappear" we probably wont have this discussion (which is good anyway).

(In reply to Heiko Tietze from comment #8)
> a document shall not be formatted with spaces or tabs.
> We have the automatic correction of (in most cases unintentionally added) tabs
> or spaces, whether trailing or leading.
I fully agree with this point. I also think the automatic correction is a useful feature.


> even if, why should we change the current behavior (given the option allows
> a different workflow too).
When following the reported steps, the way tabs and spaces are automatically removed differs between versions. I first wanted to confirm which behavior is the intended one. Based on that, I would like to propose aligning all versions to the intended behavior.

Even if the documentation is updated, users may still become confused if the actual behavior varies across versions (and in fact, I was confused myself). This is especially likely right after updating LibreOffice.

(In reply to Heiko Tietze from comment #8)
> I struggle a bit with the list of changes
> and what of these premises have changed.
I have reorganized the information as follows:

[Up to 25.8.3]
Bug 67797: not applied / Bug 168228: not applied
Only numbered lists remove leading/trailing tabs and spaces.

[25.8.4]
Bug 67797: not applied / Bug 168228: applied
All leading/trailing tabs and spaces are removed in all cases.

[26.2]
Bug 67797: applied / Bug 168228: not applied
All leading/trailing tabs and spaces are preserved in all cases.

[26.2 and later]
Bug 67797: applied / Bug 168228: applied
Only numbered lists preserve leading/trailing tabs and spaces.


As shown above, the combination of the two bug fixes results in four different behaviors across versions, making it difficult to determine which one is the intended behavior.

Regarding the idea of improving UI feedback:

I agree that clearer feedback would help users.

However, in order to provide meaningful and consistent feedback in the UI, the intended behavior must first be clearly defined.
If the underlying behavior differs across versions, it becomes impossible to explain in the UI what is supposed to happen and why tabs/spaces are removed or preserved.

That is why I believe clarifying and unifying the intended behavior is a necessary first step.

(In reply to Takenori Yasuda from comment #10)
> Only numbered lists preserve leading/trailing tabs and spaces.
In case of lists, whether ordered (numbers, alphanumeric etc.) or unordered (bullets, graphics etc.) the tab key does not insert the literal character but indents the level. What I can confirm is the trailing tab that is not removed for lists (minor issue and rather an inconsistency than an issue).

> [26.2 and later]
Wouldn't care too much about older versions. 

> Bug 67797: applied / Bug 168228: applied / not applied
I cannot follow you here. Do you run a self-build versions and compare the official nightly build or RC1/2 against where the patch is removed? Essentially with the idea to revert the patch?

(In reply to Heiko Tietze from comment #12)
> I cannot follow you here. Do you run a self-build version and
> compare it against official nightly/RC builds where the patch is removed?
I am only comparing officially released builds (including nightly builds and RC builds) and their observable behavior. I am not modifying or reverting any patches myself.

The "applied/not applied" labels were only meant as an annotation, because even builds with the same version string (e.g. 26.2.0.0.alpha1+) showed different behavior depending on the nightly build.  
If you simply understand that "the behavior differs across versions", that is enough for my purpose.

So please feel free to ignore that part.  
I apologize for causing confusion with my wording.

(In reply to Heiko Tietze from comment #12)
> In case of lists, ...
How about normal paragraphs? As described in the original report, a manually entered literal tab character remains in 25.8.3, but is removed in 25.8.4, 26.2, and master (26.8).


> Essentially with the idea to revert the patch?
Reverting patches would only reintroduce past bugs, so I do not think that is a good approach.
However, even if we decide to adjust any patch here, it is difficult to make changes lightly because this area interacts with other autocorrect settings.


Therefore, my current idea is the following:

1. First determine and share a unified and clearly defined intended behavior, so that it becomes easy to judge whether a given result is a bug or intended.
2. Update the Help page for "Delete spaces and tabs at beginning and end of paragraph" by removing the sentence "To use this option, the Apply Styles option must also be selected", so that the documentation matches the actual behavior.
3. (Optional) Set "Delete spaces and tabs at beginning and end of paragraph" to OFF by default.

(In reply to Takenori Yasuda from comment #14)
> 1. First determine and share a unified and clearly defined intended
> behavior, so that it becomes easy to judge whether a given result is a bug
> or intended.
Thought I have done this but there are more questions around this feature.

Bug 139963 - "Delete spaces and tabs at end and start of line" option in AutoCorrect needs critical evaluation (dealing with the dichotomy paragraph and line)
Bug 139986 - Some problems with "Delete spaces and tabs at beginning and end of paragraph" option in AutoCorrect (about the apply style)

> 2. Update the Help page...
Sure
> 3. (Optional) Set "Delete spaces and tabs at beginning and end of paragraph"
> to OFF by default.

Duplicate of gug 161866 - AutoCorrect options: Default settings should respect relationship between "Apply Styles" and "Delete spaces..." (disable at least while typing).

Created attachment 204927 [details]
screenshot showing new style fixes problem (non-printable chars showing)

I opened Libre office writer.
I turned on non-printable char showing.
I did a tabbed indent with text, did NOT press enter at the end.
I highlighted THAT line, from start to end.
I did SHIFT and F11 to invoke "New Style from Selection"
I named the new style Indented Paragraph.
I tested it, and it seemed to work.
I welcome comments from others, did it work for them? YES / NO
I'm NOT a programmer but can we call this a FIX?
PS  What I have not tested is if it works AFTER quitting the app and going back in, or AFTER a reboot of windows 11.  But I will update on that soon (20 minutes).

Quit app and started again - didn't save the document LOL, so lost the style entry BUT - the TAB stays there, if no other text put on that line!

TAB followed by ENTER only, looks normal, indented.

TAB followed by some text, and THEN ENTER, it removes (or autocorrects) the TAB. Has anyone tried manual fix of the autocorrect entries?

*** Bug 170301 has been marked as a duplicate of this bug. ***

(In reply to Stu Mountjoy from comment #16)
> I opened Libre office writer.
> I turned on non-printable char showing.
> I did a tabbed indent with text, did NOT press enter at the end.
> I highlighted THAT line, from start to end.
> I did SHIFT and F11 to invoke "New Style from Selection"
> I named the new style Indented Paragraph.
> I tested it, and it seemed to work.

What does "work" mean in this context? What kind of test did you perform?

> I'm NOT a programmer but can we call this a FIX?

I don't see how. What you did constitutes a fix. Plus, we seem to be at a point of need to discuss desired behavior, anyway.

I have since noticed there is ONE setting about removing tabs from a line, so I have turned THAT setting OFF - I am happy with my own 'fix'.  Please close this ticket or bug report. 

When indenting a paragraph, I expect the tab to STAY, not be removed, but for those who need it, I fully understand why THAT option exists.

BEFORE my fix, tab was removed, and I didn't want that.

AFTER my fix, tab stayed there, my preferred style.

MY test, do a tab (press TAB on keyboard) indenting the line or paragraph, type a paragraph, press ENTER on the keyboard, tab still there, user happy.

It used to remove the tab, now it doesn't.  Only a video attached LOL, would show you.  But I am happy, if others are too, to close this bug report (169751).

We discussed the topic in the design meeting.

My previous arguments are based on the false assumption that Apply Styles is unrelated to Delete Tab/Spaces. In fact, if the paragraph begins with a tab and Apply Styles is active this style adjusts automatically to Body Text, Hanging Indent. If not, the tab will be deleted (unless the option is also off).

While I personally would favor simplicity with no weirdly overloaded functions, we agree that the current behavior should be kept.

I wonder if anything is left open, Takenori,

(In reply to Heiko Tietze from comment #21)

I agree with the direction decided in the design meeting and will follow it.

Before proceeding further, I would like to confirm one point for the record.

Is it correct to understand that, for the sake of maintaining backward compatibility, the behavior of the latest version in each release series is considered the intended (de facto) specification?

(In reply to Takenori Yasuda from comment #22)
> Is it correct to understand that, for the sake of maintaining backward
> compatibility, the behavior of the latest version in each release series is
> considered the intended (de facto) specification?
In general yes, but not if it's a regression. I think we have to check the patches what intention the author had and why s/he changed something.

(In reply to Heiko Tietze from comment #23)
> In general yes, but not if it's a regression. I think we have to check the
> patches what intention the author had and why s/he changed something.
Thanks for the clarification.  
Understood — the latest version's behavior is treated as the intended specification unless it is a regression, in which case the original intention of the patch should be restored.

No further questions from my side.

(In reply to Takenori Yasuda from comment #24)
> No further questions from my side.

Resolve NAB or forward to documentation?

(In reply to Heiko Tietze from comment #25)
> Resolve NAB or forward to documentation?
NAB is fine from my side.  
Alternatively, feel free to forward it to Documentation if you think it's appropriate.

(In reply to Takenori Yasuda from comment #26)
> feel free to forward it to Documentation
Olivier is on CC

Created attachment 205081 [details]
bug 169751 - centered on equal sign-demo file

First I though that there is no real application for a user really wanting an indent that couldn't solved with a setting for the paragraph.

Today I came across a list with entries like "X = Y" and the list was centered on the equal sign (=) in paragraph > tabulator.
You need to press 'Enter' to get to the next line (of course), but here you also _need_ to add a tab indent for the line to be centered on the equal sign. However, the tab spacing is removed on pressing enter.

I'm not suggesting to change the outcome, it's just meant as small note if this ever comes up in a search (well, more than likely not)

(In reply to BDF from comment #28)
> Today I came across a list with entries like "X = Y" and the list was
> centered on the equal sign (=) in paragraph > tabulator.
And still the 11th commandment is valid: Thou shalt not format with tab and space.

While you always can switch off the automatic correction, adding one character to the last long word breaks the alignment. Same when you change the font. It's much safer to go with a table for structured content. And as a remark, Writer is a text processor and designed for running text.

*** Bug 170423 has been marked as a duplicate of this bug. ***