Also in
Version: 7.0.0.0.beta1+ (x64)
Build ID: 2891e91a513520d68ea2b8c59c14335861a15253
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL

and in
Version: 6.0.6.0.0+
Build ID: c30963b8b4bbbe42a24b97aafa161eff9d7ccdd4
CPU threads: 4; OS: Windows 6.3; UI render: default; 
Locale: nl-NL (nl_NL); Calc: CL

it's fine in
Versie: 4.4.7.2 
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: nl_NL

Also in
Versie: 5.3.5.2 
Build ID: 50d9bf2b0a79cdb85a3814b592608037a682059d
CPU-threads: 4; Besturingssysteem:Windows 6.2; UI-render: standaard; Layout Engine: new; 
Locale: nl-NL (nl_NL); Calc: CL

and in
Versie: 5.1.6.2 
Build ID: 07ac168c60a517dba0f0d7bc7540f5afa45f0909
CPU Threads: 4; Versie besturingssysteem:Windows 6.2; UI Render: GL; 
Locale: nl-NL (nl_NL); Calc: CL

still OK in
Versie: 5.0.0.1 
Build ID: 9a0b23dd0ab9652e0965484934309f2d49a7758e
Locale: nl-NL (nl_NL)

Created attachment 172828 [details]
Bibisect log

Bisected to:
author	Michael Stahl <mstahl@redhat.com>	2015-09-07 21:52:49 +0200
committer	Michael Stahl <mstahl@redhat.com>	2015-09-07 22:00:27 +0200
commit 5adc8ee343e5c32d30095bc4005b7b022016b745 (patch)
tree 8148a23a2b68e26b43a308c71fac3feb43319814
parent 4ff0032528d7aebb0de5cf045a39972a2769029f (diff)
sw: fix newly created document being modified
After the document is created, an event is dispatched on the main loop
that calls SfxPickList::Notify(), which modifies document properties.

It tries to prevent setting the document to modified by calling
SfxObjectShell::EnableSetModified(false), but Writer cunningly outwits
it by simply having its own independent(?) modified flag that is set
unconditionally in DocumentStatisticsManager::DocInfoChgd().

Let's assume that if the modified flag shouldn't be modified in
SfxObjectShell, it shouldn't be modified in DocumentStatisticsManager.

Somehow in 4.4 and 4.3 the same thing was going on, but it didn't result
in a visibly enabled Save icon in the UI, but with 5.0 it does - cannot
easily bisect why that changed due to tdf#91383.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=5adc8ee343e5c32d30095bc4005b7b022016b745

I confirm the behaviour, but the problem is, that - while typing CTRL-Z - RBs is added to AutoCorrect Exceptions

Steps to reproduce
1. Assure that AutoCorrect is on with option "Correct TWo INitial CApitals" on.
2. Type "RBs" + Space. AutoCorrect auto-corrects into "Rbs "
3. Open Tools -> AutoCorrect -> AutoCorrect Options -> Exceptions: RBs is not part in list
4. Press CTRL-Z (3x) to undo every action 
5. Open Tools -> AutoCorrect -> AutoCorrect Options -> Exceptions: RBs is part of the list


cc: Michael Stahl

Tested with
Version: 7.3.0.0.alpha0+ (x64) / LibreOffice Community
Build ID: 949658028e722e5d2657b503eb20e16e41dbd8cf
CPU threads: 4; OS: Windows 10.0 Build 19043; UI render: Skia/Raster; VCL: win
Locale: de-DE (de_DE); UI: en-GB
Calc: CL

Caolán McNamara committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/75a14a1e962793de1483ceea1bc36cc78144e386

Related: tdf#142719 first time undo adds an exception it gets lost

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.

As far as I can tell this is intentional. If the user undos the "two initial capitals" autocorrect (as the next thing the user does after the autocorrect) then a new persistent rule is added to not do that autocorrect again. I see the code for this exists back in the "Initial import" from 2000.

What I also see is there's a different type of bug where (typically on first start) if there is no preexisting autocorrect exception file then the first undo of an autocorrect results in an exception rule which doesn't get saved by accident, while later undos of an autocorrect do have their exception rule saved

Caolán McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-7-2":

https://git.libreoffice.org/core/commit/5cfe6907be9d7fec09c10db59a1fb29c278c23a5

Related: tdf#142719 the first time undo adds an exception it gets lost

It will be available in 7.2.4.

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.

7.2.4 was a hotfix release, updating target in status-whiteboard

(In reply to Caolán McNamara from comment #6)
> As far as I can tell this is intentional. If the user undos the "two initial
> capitals" autocorrect (as the next thing the user does after the
> autocorrect) then a new persistent rule is added to not do that autocorrect
> again. I see the code for this exists back in the "Initial import" from 2000.
This is true is if (a) "autoinclude" is enabled on  Tools - AutoCorrect - AutoCorrect Options - Exceptions tab, and  (b) Tools - AutoCorrect - While Typing is enabled.

It is even documented: https://help.libreoffice.org/latest/en-US/text/shared/01/06040300.html#bm_id6384777