Bug 67743 - can't save new autocorrect entries or delete existing ones
Summary: can't save new autocorrect entries or delete existing ones
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Linguistic (show other bugs)
Version:
(earliest affected)
4.1.0.3 rc
Hardware: All All
: high major
Assignee: Caolán McNamara
URL:
Whiteboard: target:4.2.0 target:4.1.1
Keywords: regression
: 67765 68520 68860 (view as bug list)
Depends on:
Blocks: mab4.1
  Show dependency treegraph
 
Reported: 2013-08-04 14:38 UTC by tommy27
Modified: 2013-09-02 19:46 UTC (History)
13 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 tommy27 2013-08-04 14:38:32 UTC
tested on Win7 64bit with Version: 4.2.0.0.alpha0+
Build ID: 2382b8e8ec0ea65dc2a9ad1c401abe3be35a1487
TinderBox: Win-x86@6-debug, Branch:master, Time: 2013-08-02_23:15:16

Steps to reproduce:

1-  load the autocorrect replacement table (Tools/Autocorrect options/Replace)
2-  insert a custom autocorrect entry in the "replace" and "with" fields
3-  click "new" and "ok" buttons to save the new addition
4-  reopen the replacement table

Expected behaviour: the new added entry should be part of the list.

Current behaviour: the new added entry is not present.

it seems that saving new entries in the autocorrect replacement table is broken.
it works fine in 4.0.4 and 4.1.0 final release.

adding to the mab4.2 list since an important functionality is not working anymore.
Comment 1 m.a.riosv 2013-08-04 15:05:51 UTC
Hi tommy27, thanks for reporting.

I can not reproduce with:
Win7x64i3Ultimate
Version: 4.2.0.0.alpha0+ Build ID: aa5683e18de07c9e86325595ead4574efa685c3a
TinderBox: Win-x86@6-debug, Branch:master, Time: 2013-08-04_00:00:18

Have you tried resetting the user profile?.

What do you enter in "replace" and in "with".

Before a confirmation changed the status to medium and normal.
Comment 2 tommy27 2013-08-04 20:20:17 UTC
still having the same issue with clean profile on Win7 64bit and a new master build.

Version: 4.2.0.0.alpha0+
Build ID: aa5683e18de07c9e86325595ead4574efa685c3a
TinderBox: Win-x86@6-debug, Branch:master, Time: 2013-08-04_00:00:18
Comment 3 m.a.riosv 2013-08-04 20:32:05 UTC
We need some else take a look to this report, and verify the issue. So changed the status to unconfirmed.
Comment 4 tommy27 2013-08-05 07:10:41 UTC
I installed 4.2alpha twice (2 different builds) and in each case the user profile was clean.
browsing the user folder I see that no autocorr subfolder exists and even if you try adding new autocorrect entries that folder is not created.

if you manually copy the autocorr subfolder from another user profile and put it inside the 4.2dev user folder, then autocorrect entries can be saved and stored regularly.

from what I see, the issue is that LOdev fails to create a new autocorr subfolder if no such folder is already present.
Comment 5 m.a.riosv 2013-08-05 19:28:38 UTC
*** Bug 67765 has been marked as a duplicate of this bug. ***
Comment 6 tommy27 2013-08-06 07:39:49 UTC
4.2alpha can't store new autocorrect entries.

4.1.0.4 can store new autocorrect entries but unlike previous releases, custom autocorrect entries are not stored in user profile "...User\LibreOffice 4\user\autocorr" (this subfolder is not created in the user profile)

it seems that new autocorrect entries stay in default autocorrect databases stored in "...Bin\LibreOffice 4\share\autocorr"

I don't know if this is intended or not... however even if autocorrect works in 4.1.x the location is not correct... that stuff must stay in the user profile to allow future migration of those data.

do I need to file a separate bug report regarding this?
Comment 7 Mike Kaganski 2013-08-06 09:03:23 UTC
I am not sure that Bug 66765 is a dupe of this. This one is about 4.2 alpha under Windows, and that is about 4.1 under Linux. And I cannot reproduce the bug 66765 under Win7x64 with 4.1.0.4. Further, as far as I can tell, the autocorrection database for 4.1 is stored (at least in my system) in "%userprofile%\AppData\Roaming\LibreOffice\4\user\autocorr".

So, I suggest:
1. Mark Bug 66765 as UNCONFIRMED again (until it is confirmed by some Linux user).
2. File a distinct bug report about some installations of 4.1 in Windows where the autocorrection DB is stored in wrong path.
3. Mark these three bugs as see also to each other.
Comment 8 tommy27 2013-08-06 12:23:49 UTC
@Mike
1- the correct number for the duplicate bug you are talking about is Bug 67765 

2- maybe you are right... we are probably dealing with linked yet different issues in different OS

3- the correct user profile path in Win7 is ""%userprofile%\AppData\Roaming\LibreOffice\4\user\autocorr" the path I gave is that of the portable version.
could you please try to replicate the issue I saw? you should temporarily delete the autocorr subfolder from your profile, then enter some new entries in the replacemente table and see if LibO 4.1 creates a new autocorr folder in the user profile. in my system it fails doing so unless an autocorr folder is already present
Comment 9 Maxim Monastirsky 2013-08-06 14:11:50 UTC
I can confirm this bug with both 4.1.0.4 and 4.2.0.0.alpha0+ (Build ID: acdf00ea9995ba06b18c0b0ea0eb55974f1e3ae9 TinderBox: Win-x86@6-debug, Branch:master, Time: 2013-08-06_07:23:57), both on Windows 7 32-bit. Unlike what was said by tommy27, I can't see any difference between the both. So I'm also changing the 'Version' field to 4.1.0.4.

Currently, two workarounds exist:
1) Run LibreOffice as Administrator. (In this case the values stored in %ProgramFiles%\LibreOffice 4\share\autocorr. You can see it by the last modification date, and you can also unzip the files and see your saved values.)
2) Manually create %USERPROFILE%\AppData\Roaming\LibreOffice\4\user\autocorr, and copy there the file for the language you want (Without copying the files there it won't work, even if the directory exist).
Comment 10 Maxim Monastirsky 2013-08-06 14:38:56 UTC
@tommy27: I see that for 4.1.0.4 testing you used the portable version. If this is true, then you can't compare it with 4.2.0alpha, because the latter installs in %ProgramFiles% folder which is non-writable by an ordinary user (only by Administrator, that explains the first workaround from my previous comment).

@Mike Kaganski: Maybe you have the UAC disabled?
Comment 11 Maxim Monastirsky 2013-08-06 15:02:37 UTC
Reproductible on Linux too (4.1.0.4 from libreoffice.org, on Ubuntu 13.04 64-bit), including the two workarounds. So I'm pretty sure it's the same issue.

@Mike Kaganski: The fact you can't reproduce on Windows, can be also explained if you left your LO profile after uninstalling an older version.
Comment 12 tommy27 2013-08-06 18:41:31 UTC
I'm downloading right now 4.1.0 final to test on a standard install version (not portable).

it seems that the problem comes out when LibO has to create a brand new autocorrect folder, while it can work with no issue if it finds such folder from previous installation
Comment 13 Mike Kaganski 2013-08-06 22:08:26 UTC
(In reply to comment #8)
> 1- the correct number for the duplicate bug you are talking about is Bug
> 67765 

Thank you. My guilty :)

(In reply to comment #11)
> @Mike Kaganski: The fact you can't reproduce on Windows, can be also
> explained if you left your LO profile after uninstalling an older version.

You are quite right.
I can confirm this with 4.1.0.4 under Win7x64.
-LO creates fresh new user profule without autocorr directory.
-If absent, this directory is not created on Autocorrection entry addition.
-If this directory is present, and the required language file is absent in it, it is not created by program.
-If used under admin, LO stores autocorrection entries in its main autocorrection db, if conditions above are true.

So, please ignore my Comment 7.
Comment 14 tommy27 2013-08-07 07:18:38 UTC
I confirm issue on standard installation of LibO 4.1.0.4 with same behaviour  reported on 4.2alpha (interestingly the portable version from winPenPack was able to store new entries but not inside the user profile folder).

description of the bug in Comment 13 is pretty accurate.

I'm moving this bug from mab4.2 to mab4.1 and set higher importance values.
autocorrect function is completely unusable for new user who don't have a preexisting profile.
Comment 15 tommy27 2013-08-07 07:24:36 UTC
adding REGRESSION keyword since it works fine in 4.0.x branch

changing version field according to Bug 67765 description: the issue is already reported in 4.1.0.3 rc but I suspect the bug came out in earlier development 4.1.x releases... can any Linux user try to bibisect this?
Comment 16 tommy27 2013-08-08 13:06:54 UTC
My guess is that the root of the problem is that LibO fails to create a brand new autocorr folder in the right location which is inside the user profile (the Windows path is: C:\Users\YourName\AppData\Roaming\LibreOffice\4\user\autocorr

If my theory is right, LibO tries instead to save it inside C:\Program Files (x86)\LibreOffice 4\share\autocorr  but fails to overwrite the acor.dat files since they are located in a Windows system folder where overwriting is not allowed.

This is indirectly confirmed by the fact that the portable version X-LibO from winPenPack doesn't save data in the “X-LibreOffice\User\autocorr” folder as well but it's able to store the new autocorrection data inside “X-LibreOffice\Bin/share/autocorr” which is not protected unlike the standard non-portable version.

The weird thing as other user reported is that LibO correctly saves autocorrection data in the user profile if that subfolder was already present from a previous installation.
Comment 17 Commit Notification 2013-08-09 10:48:26 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=d2c3297eed9917c110da67b2a4c19265aecb38ed

Resolves: fdo#67743 user autocorr file not written



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 18 Caolán McNamara 2013-08-09 11:31:13 UTC
fixed in master, proposed for 4-1 in gerrit
Comment 19 Commit Notification 2013-08-09 13:08:16 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=447c22283f7e7d592a5653925f9c1bbc7fa3766a&h=libreoffice-4-1

Resolves: fdo#67743 user autocorr file not written


It will be available in LibreOffice 4.1.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 20 tommy27 2013-08-09 14:47:20 UTC
great fix Caolan. I hope it will make it for 4.1.1 as well.
Comment 21 Marco Polo 2013-08-12 07:30:04 UTC
I'm just a user and hit this bug right away in 4.1.0.4 I just installed on a Win7 machine. Good job of pinning it down! I created an autocorr folder where it belonged and copied my language file from Program Files\... to that folder and my autocorrects are now saved!
-Marco Polo



(In reply to comment #16)
> My guess is that the root of the problem is that LibO fails to create a
> brand new autocorr folder in the right location which is inside the user
> profile (the Windows path is:
> C:\Users\YourName\AppData\Roaming\LibreOffice\4\user\autocorr
> 
> If my theory is right, LibO tries instead to save it inside C:\Program Files
> (x86)\LibreOffice 4\share\autocorr  but fails to overwrite the acor.dat
> files since they are located in a Windows system folder where overwriting is
> not allowed.
> 
> This is indirectly confirmed by the fact that the portable version X-LibO
> from winPenPack doesn't save data in the “X-LibreOffice\User\autocorr”
> folder as well but it's able to store the new autocorrection data inside
> “X-LibreOffice\Bin/share/autocorr” which is not protected unlike the
> standard non-portable version.
> 
> The weird thing as other user reported is that LibO correctly saves
> autocorrection data in the user profile if that subfolder was already
> present from a previous installation.
Comment 22 tommy27 2013-08-12 07:46:32 UTC
@Marco Polo
yes. manual copy is a workaround to make autocorrect work again.
the bug only happens if that folder is empty at first installation.
Comment 23 tommy27 2013-08-12 07:46:45 UTC
@Marco Polo
yes. manual copy is a workaround to make autocorrect work again.
the bug only happens if that folder is empty at first installation.
Comment 24 tommy27 2013-08-13 07:47:32 UTC
@Caolan McNamara

sorry, I don't wanna seem pushy but IMHO this bug should be applied to 4.1.1 as well.

old user can easily workaround this issue, using their old profiles, but new user will face an unusable autocorrect engine.
Comment 25 Kelton Newman 2013-08-13 15:39:11 UTC
So how do I get the "autocorrect engine" to work on the installation of LibreOffice that I have installed on my computer?  Do I need to uninstall the newest version, then install an older version, then add my autocorrect entries, then install the newest version of LibreOffice?

Is there a simpler way to do this?
Comment 26 tommy27 2013-08-13 16:15:54 UTC
if you had a previous LibO version installed on your PC the old autocorrect data should be preserved in the user profile and be correctly managed by LibO 4.1.0

if 4.1.0 is your first LibO installation you just have to manually copy the autocorr folder from C:\Program Files (x86)\LibreOffice 4\share\autocorr to  
C:\Users\YourName\AppData\Roaming\LibreOffice\4\user\autocorr
Comment 27 Kelton Newman 2013-08-13 16:27:14 UTC
Alas, I'm not using the Windows version of LibreOffice, I'm using the GNU/Linux version of LibreOffice.

Never mind all this.  I'll just wait for the next release to fix the problem.
Comment 28 tommy27 2013-08-14 07:29:51 UTC
(In reply to comment #27)
> Alas, I'm not using the Windows version of LibreOffice, I'm using the
> GNU/Linux version of LibreOffice.
> 
> Never mind all this.  I'll just wait for the next release to fix the problem.


the Linux location of the user profile is here:
https://wiki.documentfoundation.org/UserProfile#GNU.2FLinux
do the same manual copy&paste I described for Windows. it should work.
Comment 29 Michael Stahl (CIB) 2013-08-14 11:36:53 UTC
mostly fixed but there is still one problem here...

the very first time with a new user profile, add an autocorrect entry as in "description", then it will work when typing the letters, but then open the "AutoCorrect Options" dialog again and the new entry is no longer there.

subsequently added entries stick around.

this works in libreoffice-4-0, so part of the regression i guess.
Comment 30 Commit Notification 2013-08-14 11:47:52 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-1-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=bf369b2c653297d722d41e56fd71425526a44a72&h=libreoffice-4-1-1

Resolves: fdo#67743 user autocorr file not written


It will be available already in LibreOffice 4.1.1.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 31 Maxim Monastirsky 2013-08-25 13:01:12 UTC
*** Bug 68520 has been marked as a duplicate of this bug. ***
Comment 32 Maxim Monastirsky 2013-08-25 13:26:23 UTC
@Caolán McNamara: I can confirm comment 29: With 4.1.1.2 using new user profile, either adding or removing items from the autocorrect list works only until next time you open the autocorrect dialog. Then even if you click 'Cancel' or just close the window, it reverts your changes. Same happens if you just close LO completely and reopen. Only second time changes are saved. Verified on Windows 7 (32-bit). Would be great if you could take a look at this. thanks.
Comment 33 Commit Notification 2013-08-27 13:52:37 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=68dea1c1b61a99cdef556ba7d8ccfdad1be8a663

Resolves: fdo#67743 ensure user autocorr config dir exists



The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 34 Commit Notification 2013-08-27 14:02:47 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=ef0a7a309d03c83f59a32595132f3f3e4c9893c0&h=libreoffice-4-1

Resolves: fdo#67743 ensure user autocorr config dir exists


It will be available in LibreOffice 4.1.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds
Affected users are encouraged to test the fix and report feedback.
Comment 35 tommy27 2013-08-31 13:35:07 UTC
I confirm that everything is fixed in Version: 4.2.0.0.alpha0+
Build ID: 94730f359023a3e90fd6d5239a12a150f41f4dd2
TinderBox: Win-x86@39, Branch:master, Time: 2013-08-31_03:30:4
Comment 36 Cor Nouws 2013-09-02 19:46:42 UTC
*** Bug 68860 has been marked as a duplicate of this bug. ***