Bug 169751 - Tab disappears after indenting and pressing Enter
Summary: Tab disappears after indenting and pressing Enter
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
26.2.0.0 alpha0+ master
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: AutoCorrect-Complete
  Show dependency treegraph
 
Reported: 2025-11-30 02:40 UTC by rram
Modified: 2025-12-18 12:21 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description rram 2025-11-30 02:40:52 UTC
In the Alpha version, indenting a paragraph and then pressing Enter—whether at the end or in the middle of the paragraph—causes the initial indent to disappear. This issue is not reproducible in the live version and appears to occur only in the Alpha build.

1) Start on a new line 
2) press tab 
3) type something
4) press enter
5) The tab from step 2 is gone


Version: 25.8.3.2 (X86_64)
Build ID: 8ca8d55c161d602844f5428fa4b58097424e324e
CPU threads: 8; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded


Version: 26.2.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 620(Build:0)
CPU threads: 8; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 1 Takenori Yasuda 2025-11-30 06:53:00 UTC
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.
Comment 2 Saburo 2025-12-08 06:19:53 UTC
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?
Comment 3 rram 2025-12-13 05:09:49 UTC
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.
Comment 4 Michael Stahl 2025-12-18 12:21:38 UTC
(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.