Bug 128956 - Switching between two versions of LibreOffice resets user profile
Summary: Switching between two versions of LibreOffice resets user profile
Status: UNCONFIRMED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
6.2.8.2 release
Hardware: All macOS (All)
: lowest normal
Assignee: Not Assigned
URL: https://wiki.documentfoundation.org/I...
Whiteboard:
Keywords: bibisectRequest, regression
Depends on:
Blocks: User-Profile
  Show dependency treegraph
 
Reported: 2019-11-22 11:49 UTC by Alex Thurgood
Modified: 2023-03-16 14:23 UTC (History)
8 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 Alex Thurgood 2019-11-22 11:49:11 UTC
Description:
1) Start LibreOffice 6332.
3) Open a new Writer document (or any new document type)
2) Configure various preferences, e.g. Java JDK. Save the changes (apply)
4) Shutdown LibreOffice

5) Start LibreOffice 6282

6) Error message about missing Java configuration
The configuration of LibreOffice has changed. Under LibreOffice - Preferences - LibreOffice - Advanced, choose the Java runtime environment you want LibreOffice to use. Click on OK.


7) Second error message about missing Java configuration
The configuration of LibreOffice has changed. Under LibreOffice - Preferences - LibreOffice - Advanced, choose the Java runtime environment you want LibreOffice to use. Click on OK.


8) If it is the first time in that particular day that the other version of LibreOffice has been started, additionally you will get the tip of the day, and the release news update banner.



Steps to Reproduce:
See above description

Actual Results:
Java configuration gets reset every time.

Expected Results:
Java configuration should be retained and not reset


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Comment 1 Alex Thurgood 2019-11-22 11:49:50 UTC
It is a major PITA

Tested on macOS Mojave 10.14.6
Comment 2 V Stuart Foote 2019-11-22 17:45:20 UTC
Why would you be using multiple versions without specifying discrete user profiles for each LO instance?

Would think for your own sanity, only one version should be in the Applications library--and certainly never with matching 'LibreOffice' program names.

Extract any other installer dmg where you like, then enter the archive and in the Program directory edit bootstraprc config chaning the $SYSUSERCONFIG/LibreOffice/4 --> $ORIGIN/../<whateverYouLike> 

LibreOffice profile created with an $ORIGIN path is internally relative to the LO package archive.  The $SYSUSERCONFIG is to your os login--probably don't want to routinely muddle your "daily" profile, with your "testing" build specific profiles.

The "Installing in parallel/OS X" wiki article [1] may need some attention if this is not clear. This looks to be the 'Old method'

=-ref-=
[1] https://wiki.documentfoundation.org/Installing_in_parallel/OS_X
Comment 3 Alex Thurgood 2019-11-23 05:35:45 UTC
1) The change in behavior is pretty recent, it has worked fine up til now, so hardly an "old" way of parallel installing. 

2) The app bundle names are different, for example:

LibreOffice
LibreOfficeDev
LO6282
LO5472
LO6132
etc

3) The whole point of parallel installation using the same profile is to:

- keep one's user profile settings intact while switching between versions
- be able to test the impact of one's user settings on different versions to report on any issues

Given that QA often recommends installing a parallel version to normal people reporting issues, do you really think that your suggestion to modify bootstraprc is going to have huge uptake? Especially since they will then have to separately copy over the bits of the user profile they want, or else configure them manually again. 

4) I imagine that tampering with the bootstraprc file might void the notarisation process on Catalina (haven't tested).
Comment 4 V Stuart Foote 2019-11-23 06:24:24 UTC
(In reply to Alex Thurgood from comment #3)
> 1) The change in behavior is pretty recent, it has worked fine up til now,
> so hardly an "old" way of parallel installing. 
> 

Sorry, I was not clear on that, was referring to the methods in the  Wiki for 'installing in parallel'. 

And in fact, both the 'new' macOS method of a helper script setting a PROFILE_DIR environment variable; or the 'old' method of manual edit of bootstraprc and setting the internal 'UserInstallation' variable to internal $ORIGIN path work with a unique profile for each LibreOffice installation.

Either method is intended to allow you to keep your operational user profile separate from your testing profile--so as to not corrupt your user profile, and reduce the frequency of needing to reset profile to restore function.

But that is not really the main issue of the comment 0 which is about your Java runtime.  For that I can not confirm as each install I perform receives its own  newly configured default profile.
Comment 5 Robert Sandberg 2019-11-26 05:37:19 UTC Comment hidden (spam)
Comment 6 Xisco Faulí 2019-11-28 12:26:02 UTC
Changing it back to medium/normal until it's confirmed
Comment 7 JosiahBryant 2021-03-17 20:43:08 UTC Comment hidden (spam)
Comment 8 Timur 2021-03-30 10:51:02 UTC
This bug is Unconfirmed for too long. 
I don't use Mac but this is a general issue. 
I don't see a need for Lo to fix this, if exists, I guess profile is not meant to be shared across different versions.
So I think this can be closed.
Comment 9 Alex Thurgood 2021-04-01 11:50:06 UTC
(In reply to Timur from comment #8)
> This bug is Unconfirmed for too long. 
> I don't use Mac but this is a general issue. 
> I don't see a need for Lo to fix this, if exists, I guess profile is not
> meant to be shared across different versions.
> So I think this can be closed.

So you close the bug as WF, whilst not being a Mac user, and therefore not being able to experience the bug in question ? Yes, that's entirely rational.

Please indicate where, in any ESC decision or QA decision, a bug should be closed as WF because it has been in the UNCONFIRMED status for "too long".

Please point me to the definition of "too long".

The fact is, the project encourages people to test multiple versions and report bugs. 

Testing against an existing profile illustrates that there continue to be issues when using a newer version against an existing profile, such as this one.

It isn't a question of sharing the profile, it is a question of what happens when a user installs an upgrade over an existing profile.
Comment 10 V Stuart Foote 2021-04-01 13:48:43 UTC
@Heiko, Tor what are you doing to configure parallel installs of LO? 

I still think Alex is incorrect attempting to run multiple instances of LO with default $SYSUSERCONFIG in the program/bootstraprc configuration file. (comment 2 comment 4).

I modify any testing installs to use $ORIGIN, certainly on Windows builds; but I don't drive macOS as often as you.

Advice?
Comment 11 Alex Thurgood 2021-04-02 09:57:48 UTC
If the decision is don't run multiple versions of LO on macOS with the same user config, then we should clearly say so, IMHO.

I think we should bear in mind that people download and install Fresh/Stable (or whatever they're called today) precisely to try and evaluate what the newer one has fixed and broken over the old one.

Modifying bootstraprc files in the app bundle is not a trivial operation for the casual user in such a situation, and probably not recommended from a macOS app bundle verification point of view (I haven't tested to check whether it does in fact cause some kind of security warning issue).

If you already have an installed version of LO, when you install a different version, you get asked whether you want to replace the existing app bundle or keep both versions. By default, macOS appends a space and a digit to the LibreOffice app bundle name. So, for a second installation, the app bundle will be named "LibreOffice 2", etc. However, it continues to use the existing user configuration.
Comment 12 V Stuart Foote 2021-04-02 14:41:11 UTC
Please see the linked URL for the Wiki "Installing in parallel/OS X"
Comment 13 Aron Budea 2021-04-03 07:21:28 UTC
I'm not in favor of closing unexplained behavior concerning user profiles without any investigation. If random settings are forgotten when switching between versions, it can be a serious issue, LibreOffice shouldn't have a problem with that. Sure, if a configuration item is made obsolete or is renamed, I can think of that as a valid reason for similar behavior when switching back to an older version.

(In reply to Alex Thurgood from comment #0)
> Actual Results:
> Java configuration gets reset every time.
> 
> Expected Results:
> Java configuration should be retained and not reset
The title has "resets user profile", while the description is only about Java settings, is any other setting reset with similar steps? If not, please adjust the title that only the Java settings are known to be affected.
Comment 14 Alex Thurgood 2021-04-03 16:21:38 UTC
(In reply to V Stuart Foote from comment #12)
> Please see the linked URL for the Wiki "Installing in parallel/OS X"

So following those instructions, there are several issues :

(1) in order for a shell script to be launchable from Finder, you need to associate it with an app. By default, Terminal.app does not have the authorisation to launch userland scripts, the user has to go and authorise this in the OS security settings.

(2) by default, no app is assigned to the execution ".sh" files, so this has to be sought out specifically, bearing in mind that Terminal.app does not appear in the list of "recommended applications" foressen by Apple. As it turned out, I have XCode installed, and this was set as the default for all ".sh" files. OK, navigated my way around that and managed to set Terminal.app as the app to open the ".sh" files by default.

(3) double clicking on the soffice.sh file from Finder gives the following from the Terminal :


alex@mbpro13 ~ % /Applications/LO/LO6461/soffice.sh ; exit;
-----------------------------------------------
  Welcome to the Wonderful World of Frogs!
-----------------------------------------------

Starting LibreOffice
find: ./Library/Application Support/MobileSync: Operation not permitted
find: ./Library/Application Support/CallHistoryTransactions: Operation not permitted
find: ./Library/Application Support/CloudDocs/session/db: Operation not permitted
find: ./Library/Application Support/com.apple.sharedfilelist: Operation not permitted
find: ./Library/Application Support/Knowledge: Operation not permitted
find: ./Library/Application Support/com.apple.TCC: Operation not permitted
find: ./Library/Application Support/FileProvider: Operation not permitted
find: ./Library/Application Support/com.apple.avfoundation/Frecents: Operation not permitted
find: ./Library/Application Support/CallHistoryDB: Operation not permitted
find: ./Library/Autosave Information: Operation not permitted
find: ./Library/IdentityServices: Operation not permitted
find: ./Library/Messages: Operation not permitted
find: ./Library/HomeKit: Operation not permitted
find: ./Library/Sharing: Operation not permitted
find: ./Library/Mail: Operation not permitted
find: ./Library/Accounts: Operation not permitted
find: ./Library/Safari: Operation not permitted
find: ./Library/Suggestions: Operation not permitted
find: ./Library/Containers/com.apple.VoiceMemos: Operation not permitted
find: ./Library/Containers/com.apple.archiveutility: Operation not permitted
find: ./Library/Containers/com.apple.Home: Operation not permitted
find: ./Library/Containers/com.apple.Safari: Operation not permitted
find: ./Library/Containers/com.apple.iChat: Operation not permitted
find: ./Library/Containers/com.apple.CloudDocs.MobileDocumentsFileProvider: Operation not permitted
find: ./Library/Containers/com.apple.mail: Operation not permitted
find: ./Library/Containers/com.apple.Notes: Operation not permitted
find: ./Library/Containers/com.apple.news: Operation not permitted
find: ./Library/Containers/com.apple.stocks: Operation not permitted
find: ./Library/PersonalizationPortrait: Operation not permitted
find: ./Library/Metadata/CoreSpotlight: Operation not permitted
find: ./Library/Metadata/com.apple.IntelligentSuggestions: Operation not permitted
find: ./Library/Cookies: Operation not permitted
find: ./Library/Caches/com.apple.HomeKit: Operation not permitted
find: ./Library/Caches/CloudKit: Operation not permitted
find: ./Library/Caches/com.apple.ap.adprivacyd: Operation not permitted
find: ./.Trash: Operation not permitted
----------------------
  Helper Script Done
----------------------
/Applications/LO/LO6461/soffice.sh: line 25: -env:UserInstallation=file:////Users/alex: No such file or directory
Saving session...
...copying shared history...
...saving history...truncating history files...
...completed.

[Opération terminée]

  

As a result, LO fails to start. Retrying leads to the same failed result.
Comment 15 Alex Thurgood 2021-04-03 16:55:08 UTC
Forgot to add that there seems to be no way to make a s ".sh" file executable from the Finder UI, so this is only possible with the chmod command from the terminal.
 
> 
> As a result, LO fails to start. Retrying leads to the same failed result.

Manually typing ./soffice.sh from a terminal leads to being asked whether or not you want to authorize access to the different services/folders (in all there were about 6 questions).

This is not for the casual user.




Additionally, opening a fresh Terminal.app windows, CD-ing to a version folder and manually launching the script leads to an application error :

alex@mbpro13 ~ % cd /Applications/LO/LO6282 
alex@mbpro13 LO6282 % ./soffice.sh               
-----------------------------------------------
  Welcome to the Wonderful World of Frogs!
-----------------------------------------------

Starting LibreOffice
----------------------
  Helper Script Done
----------------------
alex@mbpro13 LO6282 % Application Error


The same error occurs at least for L06342, LO6432, LO6282, LO6271, LO6252, LO6163, LO6062, LO5472, LO5372, LO5262, LO5162, 

LO4452 crashes on start with an Apple error message displayed

Process:               soffice [7292]
Path:                  /Applications/LO/*/LO4452.app/Contents/MacOS/soffice
Identifier:            org.libreoffice.script
Version:               4.4.5002 (0)
Code Type:             X86-64 (Translated)
Parent Process:        ??? [1]
Responsible:           Terminal [3623]
User ID:               501

Date/Time:             2021-04-03 18:50:37.281 +0200
OS Version:            macOS 11.2.3 (20D91)
Report Version:        12
Anonymous UUID:        BF7742BF-B97A-CE11-37B0-C5DBE4458374


Time Awake Since Boot: 22000 seconds

System Integrity Protection: enabled

Crashed Thread:        0  Dispatch queue: com.apple.main-thread

Exception Type:        EXC_BAD_ACCESS (SIGSEGV)
Exception Codes:       KERN_INVALID_ADDRESS at 0x0000000000000009
Exception Note:        EXC_CORPSE_NOTIFY

Termination Signal:    Segmentation fault: 11
Termination Reason:    Namespace SIGNAL, Code 0xb
Terminating Process:   exc handler [7292]


The following all hang in the macOS Dock, doing nothing, requiring force kill to close :

LO4252, LO4341
Comment 16 Alex Thurgood 2021-04-03 16:56:52 UTC
(In reply to Aron Budea from comment #13)

> The title has "resets user profile", while the description is only about
> Java settings, is any other setting reset with similar steps? If not, please
> adjust the title that only the Java settings are known to be affected.

Yes, the "Donate" nag banner and "check out what's new" nag banner.
Comment 17 Alex Thurgood 2021-12-07 12:15:29 UTC
Using the instructions :

https://wiki.documentfoundation.org/Installing_in_parallel/macOS

fails to launch any of the following older versions of LibreOffice.

LO4252
LO4341
LO4452
LO5162
LO5262
LO5372
LO5472
LO6062
LO6163
LO6252
LO6271
LO6282
LO6342
LO6432

Those instructions are still applicable for launching :  
LO6442
LO6461

and possibly later versions, although I haven't tested them.
Comment 18 Hugo 2022-02-25 09:29:49 UTC Comment hidden (spam)
Comment 19 Hugo 2022-02-25 09:32:40 UTC Comment hidden (spam)
Comment 20 Xisco Faulí 2022-05-02 11:59:48 UTC
Thanks for reporting this issue.
Could you please try to reproduce it with the latest version of LibreOffice from https://www.libreoffice.org/download/libreoffice-fresh/ ?
I have set the bug's status to 'NEEDINFO'. Please change it back to 'UNCONFIRMED' if the bug is still present in the latest version.
Comment 21 Alex Thurgood 2022-05-02 19:34:33 UTC
Still happening, with a twist. I now also get asked to authorize access by the LO application to folder X, Y, Z - usually this is either the Downloads folder or the Documents folder.
Comment 22 Alex Thurgood 2022-10-06 08:27:58 UTC
FWIW, this still occurs.

For example with LO7362 from the Apple AppStore, and LO7412 from the LibreOffice download page, the user is asked to re-authorise access to some of the folders that I presume are referenced in the recently accessed files list.
Comment 23 Timur 2022-10-06 09:22:53 UTC
This was never independently confirmed, rather closed a few times. Reporter may not put New himself.
Comment 24 Alex Thurgood 2023-03-16 13:53:18 UTC
Still happening with:

Version: 7.4.6.2 / LibreOffice Community
Build ID: 5b1f5509c2decdade7fda905e3e1429a67acd63d
CPU threads: 8; OS: Mac OS X 13.2.1; UI render: default; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

from the AppStore

and

Version: 7.5.1.2 (AARCH64) / LibreOffice Community
Build ID: fcbaee479e84c6cd81291587d2ee68cba099e129
CPU threads: 8; OS: Mac OS X 13.2.1; UI render: Skia/Raster; VCL: osx
Locale: fr-FR (fr_FR.UTF-8); UI: fr-FR
Calc: threaded

from the project download page.
Comment 25 Patrick Luby (volunteer) 2023-03-16 14:23:09 UTC
(In reply to Alex Thurgood from comment #22)
> FWIW, this still occurs.
> 
> For example with LO7362 from the Apple AppStore, and LO7412 from the
> LibreOffice download page, the user is asked to re-authorise access to some
> of the folders that I presume are referenced in the recently accessed files
> list.

That sounds like the normal macOS sandbox behavior. There is a whole process around "acquiring privileges to open a file" when running a Mac App Store app that do not apply to non-Mac App Store apps.

In the Mac App Store, the only way LibreOffice can open a file is if the file has previously been opened via an Open or Save dialog or buy opening by double-clicking or dragging the file from the Finder. Otherwise, opening the file will fail.

In the macOS sandbox, these "open file" permissions are temporary and are lost if they are not cached. Even if the previous permissions are cached, you have to reestablish the previous permissions *before* you try to open the file. And reestablishing previous permissions still sometimes fails.

I dealt with this in the early days of NeoOffice. I literally had to add a bunch of code *in every place that LibreOffice opens a file* that shows an open dialog for the folder that the file you want to open is in. It was awful coding that and was, at best, an elaborate hack. Plus the random Open dialog confused a lot of people. It was unmaintainable which is one of the reasons I am working on LibreOffice now.

What infuriates me is that Apple stubbornly continues to enforce their overly restrictive sandbox idea on Mac App Store apps, but non-Mac App Store have no such restrictions. If Apple's sandbox code at least triggered a native dialog along the lines of "the application wants to access this file, do you want to grant permission?" would alleviate a lot of the pain of working within the sandbox. But no, the only way to get the user's permission to open a file is to slow a generic Open dialog.