Problem description: Unable to use spellchecking as a regular user on Windows 7 and Windows 2008R2 Steps to reproduce: 1. Install LibreOffice 3.6 with default settings, as a user with Admin rights. 2. Log in as a user that is only member of the local users group. 3. Open LibreOffice and start typing misspelled words in a document. Spellcheck will not work. 4. Check Settings -> Language, no module for hunspell can be found. 5. Log in as an Admin user and step 3 will work as expected. Current behavior: Spellcheck does not work unless member of local administrators group Expected behavior: Even restricted users should be able to use spellcheck Platform (if different from the browser): Windows 7 x64 as well Windows 2008R2
I've done some additional testing, and it appears to occur when using folder redirection. I don't know if this is the same as, or at least related to https://bugs.freedesktop.org/show_bug.cgi?id=52336 and/or https://bugs.freedesktop.org/show_bug.cgi?id=36558 Also, when using redirected folders it takes several minutes to actually start LibreOffice. This is regardless if the profile is brand new or already existing.
Confirmed on IRC by "ThinkGNU-" on WinXP so put the tracker to NEW
sorry, bug confirmed + info that new LO profile solves the bug.
(In reply to comment #1) > I've done some additional testing, and it appears to occur when using folder > redirection. I don't know if this is the same as, or at least related to > https://bugs.freedesktop.org/show_bug.cgi?id=52336 and/or > https://bugs.freedesktop.org/show_bug.cgi?id=36558 From the original description, this sounds very much like the "Various problems with bundled extensions" of <https://wiki.documentfoundation.org/ReleaseNotes/3.6#Most_annoying_bugs>; see the workaround there (remove part of LibreOffice's per-user data). (It might be that in your case, LibreOffice had never been started for the given Admin user before, so that there was no old, problematic per-user data for that user, so it just looked like it works for Admin users but not for normal ones.) > Also, when using redirected folders it takes several minutes to actually start > LibreOffice. This is regardless if the profile is brand new or already > existing. See bug 53009 for the long first-start times. *** This bug has been marked as a duplicate of bug 53006 ***
No matter if I remove the extensions dir, or let LO 3.6 create an entirely new profile, spellcheck will not work. I'm not sure I understand the specifics of https://bugs.freedesktop.org/show_bug.cgi?id=53006 but since this is marked a duplicate of that bug, I guess this will all get solved with LO 3.6.1 then.
(In reply to comment #5) > No matter if I remove the extensions dir, or let LO 3.6 create an entirely new > profile, spellcheck will not work. OK, that makes it unlikely to be due to the same root cause as bug 53006, then. So back to REOPENED for now. What do you mean with "folder redirection"?
Folder redirection is where instead of having all the users data in a local profile, you redirect say %APPDATA% to another network storage. So instead of the appdata being stored in C:\users\user\appdata\roaming\ it's somewhere like \\server\share$\appdata_roaming\user\. We do this to make user profiles consistent across an RDS cluster among other things. See http://technet.microsoft.com/en-us/library/cc732275.aspx Pretty much like if you'd mount /home over an NFS share in a Linux environment, except it's for select folder and not the entire profile. Difference is that in Linux the system would still act as if the mountpoint was /home/user, and on Windows it prints the full path to the share instead of "mounting" it in the local user-profile. Since recreating a userprofile for a user with his profile stored locally makes spellcheck work, is why I'm wondering if it might be related to the bugs I mentioned in https://bugs.freedesktop.org/show_bug.cgi?id=53288#c1
Strange, I just moved AppData folder to a network share, and spellchecking works. What else can be here?
(In reply to comment #5) > I guess this will all get solved with LO 3.6.1 then. Reportedly, LO 3.6.1 test builds start to appear at <http://dev-builds.libreoffice.org/pre-releases/> now. Would be great if you could check whether it makes any difference for this problem.
(In reply to comment #9) > (In reply to comment #5) > > I guess this will all get solved with LO 3.6.1 then. > > Reportedly, LO 3.6.1 test builds start to appear at > <http://dev-builds.libreoffice.org/pre-releases/> now. Would be great if you > could check whether it makes any difference for this problem. Unfortunately not, I've tried deleting ..\extensions and restarting LO a bunch of times, as well as deleting the entire profile and doing the same. It will seemingly create the profile every time, it just won't enable spellcheck for any language. Is there a simple way to launch LO with a specific path to the profile dir? In that case I could do some trial and error with regards to where it's located.
(In reply to comment #10) > > Reportedly, LO 3.6.1 test builds start to appear at > > <http://dev-builds.libreoffice.org/pre-releases/> now. Would be great if you > > could check whether it makes any difference for this problem. > > Unfortunately not, I've tried deleting ..\extensions and restarting LO a bunch > of times, as well as deleting the entire profile and doing the same. You did that with 3.6.0 or with 3.6.1? (Not that it would probably make much difference, though...) > It will seemingly create the profile every time. Yes, both the whole user\... tree as well as just the user\extensions\... tree will be automatically created when not there at start up of LO. > Is there a simple way to launch LO with a specific path to the profile dir? In > that case I could do some trial and error with regards to where it's located. You can run soffice with a -env:UserInstallation=file:///C:/foo command-line argument to have the profile created in C:\foo, say. The only gotcha is that the argument indeed needs to be a a file URL (i.e., forward slashes, "%20" instead of a blank, etc.)
My problems with regards to speed is due to some misconfiguration with the share, so it can be disregarded. Running LO with a local profile as described in comment11 will run the app at normal speeds. Running LO with a profile in say C:\Temp\testuser results in me having access to spellcheck (hunspell). I tried pointing LO to a mapped network share, the users homefolder "W:\lo-test\" and here spellcheck also works. When folder redirection is being used, it's shown as a UNC path. E.g \\fileserver\appdata$\user\AppData\Roaming\LibreOffice\3\user\* Could this be the real issue?
this sounds related to bug 50542, btw
Yep, it seems it would be related to https://bugs.freedesktop.org/show_bug.cgi?id=50542 What I did to work around the problem was to mount %APPDATA% as X: (hidden) and then edit bootstrap.ini to use the mounted path for the profile instead. Now everything works as expected.
So - re-titling to better reflect the bug; it seems to me most likely to be a duplicate of bug#50542 - can someone confirm and mark it thus ? Either way it doesn't -appear- to be related to upgrading / migration - so dropping the migration tracker bug dependency. Hope that's ok :-)
According to my obeservations, it might well be a duplicate. Spellcheck does not work for users with roaming profiles (WinXP).
Hi, it seams that this bug is the same that I can recreate on our network: Bug 55138 and 56775 As mentionned above the path to the server is \\server\share$. LO answers the \\server\share does not exist (which is correct) as the path ends with the $ sign (hidden share on windows)
(In reply to comment #17) > Hi, > > it seams that this bug is the same that I can recreate on our network: > Bug 55138 and 56775 yes, and your description of bug 56775 made me finally realize what the root problem probably is; investigating
Closing as a dupe - if this is incorrect please set to NEW and not REOPENED. Thanks all. *** This bug has been marked as a duplicate of bug 50542 ***