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:
It is a major PITA Tested on macOS Mojave 10.14.6
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
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).
(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.
Great job! Thanks for sharing.I regularly visit your site and find a lot of interesting information. http://thestorelocator.co.uk/store/mccolls-kempston-mk42-7pr/
Changing it back to medium/normal until it's confirmed
Yeah, this issue in LibreOffice has caused a lot of troubles for me, and my https://www.easy-essay.org/case-study/ colleagues have experienced this issue, as well. Hopefully, it is solved now.
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.
(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.
@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?
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.
Please see the linked URL for the Wiki "Installing in parallel/OS X"
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.
(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.
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
(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.
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.
i want to know how to solve my site [url=https://www.justlittlethings.co.uk/write-for-us/]Fashion writes for us[/url] CSS code errors its not loading images can anybody look into this and tell me exactly what is wrong.
i want to know how to solve my site https://www.justlittlethings.co.uk/write-for-us/ CSS code errors its not loading images can anybody look into this and tell me exactly what is wrong.
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.
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.
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.
This was never independently confirmed, rather closed a few times. Reporter may not put New himself.
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.
(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.
My problem may be a consequence of this fault. When I rebooted to complete an update of LibreOffice my system (Laptop with Windows 10 Pro) had its display defined as itts display defined as portrait. How do I change this?