Description: 1) Create new Calc sheet as a non-administrator user of a macOS 10.15 system. 2) Enter some data. 3) Try to "Save As". The operation refuses to work. No Finder dialog is displayed. 4) The document title remains as Sans Nom 1 (Untitled 1) and can not be saved anywhere. 5) The beachball of death rotates for a while, then returns focus to the application. For what it is worth, the ODS file contains column headers and data from a copy/paste operation from a database table. Steps to Reproduce: See above Actual Results: Saving a Calc file is impossible. Expected Results: Be able to save a Calc file containing the copied data to a place of the user's choosing. Reproducible: Always User Profile Reset: Yes Additional Info:
See also bug 126638
*** This bug has been marked as a duplicate of bug 126638 ***
Uncoupling this from bug 126638 as I believe I have found the cause of the behaviour I reported and it appears to be different to what the OP is reporting in that bug. I have found that the problem in my case reported here in this bug report arises when there are parallel installations of LibreOffice, with names other than just "LibreOffice". It appears that the notarization process must lock in the name of the app bundle somewhere in the system, and if that name is changed, for example, when a user installs an "evolution" version of LO in parallel to a "stable" version, then calling any Finder dialog is blocked by the OS. I tried this with several different functions from within LO that are supposed to call a Finder dialog : Save as Export Adding a JAR archive under Preferences (for database driver configuration) Each time, I get a beachball and no Finder dialog, effectively blocking the operation. If I delete one of my parallel LO installations and rename the surviving one back to LibreOffice, everything seems to work as normal again. Editing title to better reflect findings.
@Choph, this issue seems to be related to the notarization process
No doubt adding the application bundle to the list of "Full Disk Access" apps might solve this. The installation should take of this, though, and it doesn't. Asking a user to specifically manually bypass the security model to allow whole disk access is bit of a problem.
I set to NEW
*** Bug 129133 has been marked as a duplicate of this bug. ***
(In reply to Alex Thurgood from comment #6) > No doubt adding the application bundle to the list of "Full Disk Access" > apps might solve this. > > The installation should take of this, though, and it doesn't. Asking a user > to specifically manually bypass the security model to allow whole disk > access is bit of a problem. On Catalina: When LO is installed (in my case with Homebrew) "Save" and "Save as" dialogs run fine, but once the LO app is **changed** by running a language pack (installer), these (Finder) dialogs cannot be invoked any more. By adding the (changed) LO app to the list of apps that are allowed "Full Disk Access", then the save dialogs can be invoked again. In short: your suggestion is correct and relevant for the installation of language packs, because that installation should also refresh any relevant permission for the (changed) LO app.
The part "with parallel LO installations" could very well be dropped from the summary.
*** Bug 131017 has been marked as a duplicate of this bug. ***
*** Bug 130883 has been marked as a duplicate of this bug. ***
*** Bug 131666 has been marked as a duplicate of this bug. ***
*** Bug 128690 has been marked as a duplicate of this bug. ***
*** Bug 130209 has been marked as a duplicate of this bug. ***
So I installed Catalina on a fresh drive to investigate this issue. As far as I can tell, this may be related to the code signing that is broken. Granting "Full Disk Access" makes the issue go away
This may be hard to replicate, as now my copy of LO on a standard account is working without Full Disk Access. It may be because I manually verified using the command line to check the output from bug 126409, I don't know. It's best done on a completely fresh install on a new Standard user to mimic what a new user would encounter Version: 6.4.2.2 Build ID: 4e471d8c02c9c90f512f7f9ead8875b57fcb1ec3 CPU threads: 4; OS: Mac OS X 10.15.4; UI render: default; VCL: osx; Locale: en-US (en_NO.UTF-8); UI-Language: en-US Calc: threaded
Reproduced with Version: 7.0.0.0.alpha1 Build ID: 6a03b2a54143a9bc0c6d4c7f1... CPU threads: 8; OS: Mac OS X 10.15.4; UI render: GL; VCL: osx; Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded
*** Bug 133044 has been marked as a duplicate of this bug. ***
*** Bug 131292 has been marked as a duplicate of this bug. ***
*** Bug 132025 has been marked as a duplicate of this bug. ***
As already suggested in duplicate Bug 132025: Maybe running codesign -vvv --deep --strict LibreOffice.app automatically by the language pack installer would solve the problem?
*** Bug 134547 has been marked as a duplicate of this bug. ***
*** Bug 135353 has been marked as a duplicate of this bug. ***
*** Bug 134848 has been marked as a duplicate of this bug. ***
Env: macOS 10.15.5 catalina. Just tested with version 7.0.0.3 Situation exactly the same. Still can't "save as", "save a copy". Don't want to change the security settings on my Mac. Going back to LO 6.3.6.2 where the problem does not exist (at least not on my Mac). I am very diapointed...
(In reply to Rob from comment #26) This still works, even with 7.0.0.3 release, and does not imply weakened macOS security settings: > codesign -vvv --deep --strict /Applications/LibreOffice.app Couldn't this just be added to the langpack installer routine?
*** Bug 135481 has been marked as a duplicate of this bug. ***
*** Bug 135511 has been marked as a duplicate of this bug. ***
(In reply to cpohle from comment #27) > This still works, even with 7.0.0.3 release, and does not imply weakened > macOS security settings: > > codesign -vvv --deep --strict /Applications/LibreOffice.app > > Couldn't this just be added to the langpack installer routine? This works for me... Agree with cpohle that it's odd that this isn't addded to the language installer. The bproblem exists in all versions after 6.3.6.2; Totally unclear to me why version 6.3.6.2 does work 'out of the box'. Anyway, as the solution seems to be known, how much work is involved in implementing this?
*** Bug 135564 has been marked as a duplicate of this bug. ***
Same problem, unable to Save As a new document. LibreOffice 7.0.0.3 MacOS Catalina 10.15.6
(In reply to Tim from comment #32) > Same problem, unable to Save As a new document. > > LibreOffice 7.0.0.3 > MacOS Catalina 10.15.6 For me the command described in Comment #c27 solved the problem.
Same problem with Version: 7.0.0.3 Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU-Threads: 4; BS: Mac OS X 10.15.6; UI-Render: Standard; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded on macOS Catalina 10.15.6 Also for me this solved the problem 1. Open console 2. change the directory to the app folder 3. codesign -vvv --deep --strict LibreOffice.app
Also having this problem after installing on Mac OS 10.15.6. Providing full disk access fixed the problem. There is another problem here in that the beachball just spins and then the focus returns to the app with no explanation. There should at least be a modal dialog explaining what happened. Clearly the installation process is not working as seamlessly as it should.
*** Bug 136759 has been marked as a duplicate of this bug. ***
Had the problem back after updating to LO 7.0.3.1 Solved by re-executing: codesign -vvv --deep --strict /Applications/LibreOffice.app
Definitely comes under "Most Annoying" bugs - oh, wait, we don't have that any more. Every time there's a version change of LO, the whole thing raises its ugly head again.
*** Bug 139679 has been marked as a duplicate of this bug. ***
*** Bug 139410 has been marked as a duplicate of this bug. ***
I had the first occurrence of this with LO 7.1 / MacOS 10.15.7 called from command line, "File open" immediately after starting the program throws: uwealtmann@UwesMacBookAir ~ % /Applications/LibreOffice.app/Contents/MacOS/soffice SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. 2021-02-05 18:37:10.792 soffice[1586:24735] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted 2021-02-05 18:37:20.957 soffice[1586:24787] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted 2021-02-05 18:37:31.036 soffice[1586:24787] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. "New Document" even crashes into document restore with the same output. Funny thing is that 7.0.4 does open the Finder's file open dialog as well as a new document, but also throws: SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details. - but nothing else.
Funny thing which should be remarked: Opening of files shown in StartCenter by click on them works as expected.
Investigation further (Catalina 10.15.7): renaming user folder and doing clean install of LO 6.4.7, adding german langPack, not having Full Disk Access. Starting from console as user, Create New document is OK, save works OK Opening existing Document works, but throws five times „(pkix_CacheCert_Add: PKIX_PL_HashTable_Add for Certs skipped: entry existed“. Later doing the same these messages do not repeat. Save this changed Document works. Doing clean install of LO 7.0.4, not having Full Disk Access everything described above works OK Doing clean install of LO 7.1.0, not having Full Disk Access Starting from console as user, Create New document is OK, save throws 2021-02-11 09:41:31.302 soffice[92346:1589178] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted 2021-02-11 09:41:41.401 soffice[92346:1589522] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted 2021-02-11 09:41:51.538 soffice[92346:1589629] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted Open and save of a recently opened document from StartCenter works. "File open" throws 2021-02-11 09:44:05.786 soffice[92346:1590496] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted 2021-02-11 09:44:15.944 soffice[92346:1590488] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted 2021-02-11 09:44:26.033 soffice[92346:1590674] +[NSXPCSharedListener endpointForReply:withListenerName:]: an error occurred while attempting to obtain endpoint for listener 'com.apple.view-bridge': Connection interrupted Starting from console as sudo, Create New document is OK, save is OK Open and save of a recently opened document from StartCenter works. "File open" Opening existing Document works, save this changed Document works also. Using LO 7.0.4 as user not having Full Disk Access After having installed "Language toll" Extension, opening a document still works but throws SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder". SLF4J: Defaulting to no-operation (NOP) logger implementation SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.
Updated to 11.2 "BigSur" - and 7.1/7.1.1 works like a charm. But then: Unable even to start older versions (to test you have to rename "user" -folder in ~/Library/Application Support/LibreOffce/4/ or it quits with some error on java version at start.) 6.2. at start brings up a Dialog window ""LibrOffice can not be opened because Apple cannot look inside the app to search for malicious software" and recommends to update. OK quits the app. 6.3. dies silently; started at command line, it just says "Application Error" and quits.
I have the same problem using Draw v 7.1.2.2
*** Bug 143681 has been marked as a duplicate of this bug. ***
(In reply to Alex Thurgood from comment #0) > Description: > 1) Create new Calc sheet as a non-administrator user of a macOS 10.15 system. > 2) Enter some data. > 3) Try to "Save As". The operation refuses to work. No Finder dialog is > displayed. > 4) The document title remains as Sans Nom 1 (Untitled 1) and can not be > saved anywhere. > 5) The beachball of death rotates for a while, then returns focus to the > application. > Repro Created a new account with standard access rights. -The document cannot be saved with read-only access. If you give a standard user access to the LA Read/write application, the bug will disappear. Additional Info: Version: 7.3.0.0.alpha0+ / LibreOffice Community Build ID: 246f24ebc8227345f13784d9e2f055d813f3d24f CPU threads: 12; OS: Mac OS X 10.15.7; UI render: default; VCL: osx Locale: ru-RU (ru_UA.UTF-8); UI: en-US Calc: threaded Version: 7.1.5.2 / LibreOffice Community Build ID: 85f04e9f809797b8199d13c421bd8a2b025d52b5 CPU threads: 12; OS: Mac OS X 10.15.7; UI render: default; VCL: osx Locale: ru-RU (ru_UA.UTF-8); UI: en-US Calc: threaded
(In reply to Denys Prokhorov from comment #47) > Repro > Created a new account with standard access rights. > -The document cannot be saved with read-only access. > > If you give a standard user access to the LA Read/write application, the bug > will disappear. Would the workaround provided in comment #22 solve the bug for you?
*** This bug has been marked as a duplicate of bug 136981 ***
Sry missclick to duplicate Bug 136981 (In reply to cpohle from comment #48) > (In reply to Denys Prokhorov from comment #47) > > > Repro > > Created a new account with standard access rights. > > -The document cannot be saved with read-only access. > > > > If you give a standard user access to the LA Read/write application, the bug > > will disappear. > > Would the workaround provided in comment #22 solve the bug for you? this does not solve the problem
*** Bug 136981 has been marked as a duplicate of this bug. ***
Still in 7.2.0.4. Would sudo codesign -vvv --deep --strict /Applications/LibreOffice.app really be so difficult to add to the installer routine?
*** Bug 144964 has been marked as a duplicate of this bug. ***
> adding German langPack But adding langpacks is known to by definition break things, as it plonks stuff into the app bundle and thus makes the signature of the app bundle invalid, no? Doing that when investigating this bug only confuses things.
So is this basically a duplicate of the old bug that says that installing langpacks the way it is done (and has always been done), separately into an already installed LibreOffice app bundle, is broken by design?
Again, not knowing the internals of how the installer works: Would it not be a feasible solution to just run the one-liner from comment 52 at the end of the installation routine to work around this "design issue"?
(In reply to Tor Lillqvist from comment #54) > But adding langpacks is known to by definition break things, as it plonks > stuff into the app bundle and thus makes the signature of the app bundle > invalid, no? The signature gets checked only at first start of the app. We changed this since years so the installer first starts and quits LO in the background (this is why it takes so long to start) and then "plonks stuff" - which worked rather good for a long time.
> The signature gets checked only at first start of the app. Trusting that sounds like a very ad-hoc hack. Not surprising if it doesn't work any longer. We should have made LO look for translations and other lang pack contents in another place than in the app bundle long ago. (I tried some year ago but it was much harder than expected (like most things in LO are) and I wasn't going to spend weeks on it.)
The problem is still present in current production releases. LO doesn't seem to follow the guidelines here: https://support.apple.com/fr-fr/guide/security/secddd1d86a6/web The app should prompt the user each time it requires access to an as yet unauthorised folder (be that local or remote), including on installation of a new version.
*** Bug 143531 has been marked as a duplicate of this bug. ***
*** Bug 140181 has been marked as a duplicate of this bug. ***
*** Bug 137909 has been marked as a duplicate of this bug. ***
(In reply to eisa01 from comment #62) > *** Bug 137909 has been marked as a duplicate of this bug. *** I don't think 137909 /is/ the same as 128233. In this report, (128233), the dialog bog is described as never appearing. In the case of 137909 the dialog box does appear, but 'freezes' for about 90 seconds.
as mentioned the codesign call won't fix anything, as that's done by gatekeeper when the application is run first. Previous attempts to reproduce failed here, but I'll give it another try (will update macOS on a couple machines, so will have access to the likely-to-be-more-picky setups...)
Created attachment 178171 [details] macOS setting hindering LibreOffice to open the file dialogue (sorry it's in German) I just discovered that under "(macOS) Settings > Security > Files and Folders", access to the Documents folder was denied for LibreOffice. Once I granted access, opening the file dialogue worked as expected. I can't remember when this could have been happened, but maybe it's worth a look for others suffering from the same bug.
*** Bug 147401 has been marked as a duplicate of this bug. ***
Same issue here on any save/export/open LibreOffice documents under macOS 10.15. Additional information: - This issue does not happen from a fresh starting; it only happens after exporting files to a eg PNG file that already exists. - The dialog box does not appear, but LibreOffice is also freezing for a few second systematically. - I still can open old documents by double-cliking on them and save them without any issues. - On LibreOffice version 5 and 4, I had a similar issue with Export, however LibreOffice crashed systematically after so I did not have the issue with saving/opening new file. The trick given by @cpohle (granting acess to Libre office "(macOS) Settings > Security > Files and Folders") does not work. Actually, it was already ticked (LibreOffice asks for this access on the first use after installation, I've just checked).
(In reply to dhina from comment #67) > Same issue here on any save/export/open LibreOffice documents under macOS > 10.15. See comment 34 for another solution
Thanks, the command line (with "sudo" first) solved the issue mostly. However, when I export files to a eg PNG file that already exists, it still crashes. Am I the only one who has this issue? If yes, that should be another bug and not related to this one.
Does it make sense that on safe mode, I still have the "no Finder dialog" bug while it works without the safe mode? (after having entered the command line from comment 34)
(In reply to dhina from comment #69) > Thanks, the command line (with "sudo" first) solved the issue mostly. > > However, when I export files to a eg PNG file that already exists, it still > crashes. > > Am I the only one who has this issue? If yes, that should be another bug and > not related to this one. To be more specific to reproduce: BUG 1 - restart LibreOffice - open new Draw file - Export > PNG > press OK - Warning "image filter not found" > press OK - Error saving the document Untitled 1: General Error. General input/output error BUG 2 (variation) - restart LibreOffice - open new Draw file - Add a disk shape (for instance) - Export > PNG > press OK - Export > PNG > press OK (with the smae name) - "Untitled 1.png already exist. Would you like to replace it?" > Replace - Crash: "due to an error, LibreOffice crashed"
(In reply to Christian Lohmaier from comment #64) > as mentioned the codesign call won't fix anything, as that's done by > gatekeeper when the application is run first. > > Previous attempts to reproduce failed here, but I'll give it another try > (will update macOS on a couple machines, so will have access to the > likely-to-be-more-picky setups...) Christian: I don't know if you had some time to give a new try but would it be possible to add "strict" (since it may detect some pb) and replace "verbose" by "verbose=4" (to be sure to have max verbosity in all cases)? Several people seem to indicate that using codesign with "strict" option helped. Even if they may be wrong (I know too little about macos to tell), at worst, it shouldn't worsen (could it?) the situation and perhaps some people would search another solution if this still fails? Remark: I don't know if all the locations need to be modified https://opengrok.libreoffice.org/search?project=core&full=codesign&defs=&refs=&path=&hist=&type=&xrd=&nn=1&si=full&si=full
After some discussion with Christian following a wrong and abandoned recent patch, here are information from him (a big thanks since this tracker was really stuck!) which may help: Hypothesis: the prompt from macOS to grant access was not shown for some reason and did timeout and thus LibreOffice was blacklisted Suggestions: Reset permission for documents folder and Desktop folder respectively -> tccutil reset SystemPolicyDocumentsFolder and/or -> tccutil reset SystemPolicyDesktopFolder (beware, without any additional parameter this will reset the permissions for all apps) It can be done only for LibreOffice: -> tccutil reset SystemPolicyDocumentsFolder org.libreoffice.script -> tccutil reset SystemPolicyDesktopFolder org.libreoffice.script it's possible to reset every privacy decision related to LibreOffice use -> tccutil reset All org.libreoffice.script Remarks: - it should work as admin user or as standard user - when running from terminal by launching /path/to/LibreOffice.app/Contents/MacOS/soffice it will be the Terminal's permissions that are applied, you'd have to use "open /path/to/LibreOffice.app" or run it from finder to have it run in its own scope To be even more complete, you can try: * reset permissions using the "tccutil reset All org.libreoffice.script" command mentioned above * drag LibreOffice to a folder on disk A) run LibreOffice without installing the languagepack first you get the gatekeeper prompt whether you want to run the application LibreOffice launches in English, as expected. Create a new file Hit save, file dialog defaults to Documents directory, on hitting "Save" → macOS should prompt and ask whether to grant LibreOffice permission to access the Documents folder → approve and LO should save successfully. → new documents should be saved to documents folder without a second prompt Use Save as (or just create another document, doesn't make a difference) and select the Desktop folder in the file selector, on hitting "save" → macOS should prompt and ask whether to grant LibreOffice permission to the Desktop folder → approve and LO should save successfully → further saves to the Desktop shouldn't trigger the prompt close LibreOffice and install the languagepack launch LibreOffice again and now shoud come up in translated form saving documents to desktop or documents folder shouldn't trigger a prompt and work B) install the languagepack without launching LibreOffice first → after hitting "install" in the languagepack installer it should trigger launching LO and the gatekeeper should prompt asking whether you want to launch LibreOffice approve and the languagepack installation should continue B.1) after languagepack installation is complete, LO shoud still run, close and restart to use it in the new locale creating documents and saving them should work as above, first time you try to access Documents or Desktop you get the permission prompt, subsequent ones should work without interruption. B.2) after languagepack isntallation create a document in the still-running English LO and save should get the prompts as expected and save works. after relaunching to switch to the new UI language saving should work without additional prompts. For those using homebrew, the mechanism is specific, bugtracker is about installing from dmg. So if after having applied all these someone still has a problem, please provide a step by step process to reproduce this. Let's put this one to NEEDINFO meanwhile.
(In reply to Julien Nabet from comment #73) @Julien: > Suggestions: > Reset permission for documents folder and Desktop folder respectively > -> tccutil reset SystemPolicyDocumentsFolder > and/or > -> tccutil reset SystemPolicyDesktopFolder > (beware, without any additional parameter this will reset the permissions > for all apps) > People should be aware of the downsides of playing with tccutil: https://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy-protections-by-accident-and-design/ Presumably, an unprivileged user, i.e. a Standard account, will not be able to wreak any system havoc with those commands ?
(In reply to Alex Thurgood from comment #74) > (In reply to Julien Nabet from comment #73) > > People should be aware of the downsides of playing with tccutil: > > https://www.sentinelone.com/labs/bypassing-macos-tcc-user-privacy- > protections-by-accident-and-design/ > > Presumably, an unprivileged user, i.e. a Standard account, will not be able > to wreak any system havoc with those commands ? I don't know. I suppose you must be careful when using this type of command. Perhaps there's also a GUI allowing to do the same but with warnings just in case. BTW, did you give it a try and did it help?
the article mentions nothing about being able to bypass any restrictions by using the tccutil command. Sure, if you mess with the database file directly like in the sample at the top of the article, you can do whatever, but the tccutil utility can only reset the permissions, remove any given consent or denial so that macOS will prompt again the next time the app tries to use the resource.
Not sure why this bug is now in NEEDINFO state. Be that as it may, a decision needs to be made as to whether this is WFM from the point of view of the TDF Apple AppStore release, or whether it should be maintained as NEW with regard to the TDF download release from the LibreOffice download site.
No pb to put it back to NEW.
@Patrick Another lovely bug. 24 duplicates, 40 people in CC. You likely tackled this problem before..
(In reply to Telesto from comment #79) > @Patrick > Another lovely bug. 24 duplicates, 40 people in CC. You likely tackled this > problem before.. If you want my opinion, there is one simple solution: ship all languages in the main download. I started doing that with NeoOffice a decade ago. It is how applications are normally shipped in the Mac App Store. I assume this whole language pack was a quick hack to reduce TDF's bandwidth usage. I also assume this is one of the reasons that TDF doesn't ship a Universal installer and macOS Silicon users get the Intel version by default (all macOS browsers have frozen their user agent strings to macOS 10.5 Intel so TDF's download website is broken in its current form). I understand why these hacks came about. A decade ago, bandwidth was much more expensive than it is now and macOS didn't have any no digital signing, notarization, sandboxing, or hardened runtime. But times have changed, TDF has lots of mirrors and bandwidth is significantly cheaper than then. So my only question about this bug is why hasn't TDF just switched macOS to a single installer? Is it increased bandwidth cost too much? If so, how much is that increased cost?
(In reply to Patrick Luby from comment #80) > (In reply to Telesto from comment #79) > So my only question about this bug is why hasn't TDF just switched macOS to > a single installer? Is it increased bandwidth cost too much? If so, how much > is that increased cost? The Appstore version includes a selection of languages (not sure how many) and does not include outside libs, or any working Java functions (despite the Uno call entries still being in the menus). When TDF started offering LO via the Appstore, it pretty much just adapted the build script used by Collabora, or at least, so it seems, as the same bugs/limitations already in Collabora Productivity can be found LO Appstore version. For people who use databases at work everyday, the appstore versions, whether Collabora or TDF, are a crippled disappointment, hence the need to be able to download a separate TDF DMG version which doesn't have these limitations. I can't say whether bandwidth considerations are still an issue for these language "neutral" versions.
(In reply to Patrick Luby from comment #80) > (In reply to Telesto from comment #79) > > @Patrick > > Another lovely bug. 24 duplicates, 40 people in CC. You likely tackled this > > problem before.. > > If you want my opinion, there is one simple solution: ship all languages in > the main download. I started doing that with NeoOffice a decade ago. It is > how applications are normally shipped in the Mac App Store. > > I assume this whole language pack was a quick hack to reduce TDF's bandwidth > usage. I also assume this is one of the reasons that TDF doesn't ship a > Universal installer and macOS Silicon users get the Intel version by default > (all macOS browsers have frozen their user agent strings to macOS 10.5 Intel > so TDF's download website is broken in its current form). > > I understand why these hacks came about. A decade ago, bandwidth was much > more expensive than it is now and macOS didn't have any no digital signing, > notarization, sandboxing, or hardened runtime. But times have changed, TDF > has lots of mirrors and bandwidth is significantly cheaper than then. > > So my only question about this bug is why hasn't TDF just switched macOS to > a single installer? Is it increased bandwidth cost too much? If so, how much > is that increased cost? +1 See also the unfortunately closed (why?) bug 89657 and the comments and discussion there. The whole situation is still unacceptable and actually unreasonable, especially for the average user. We can do better.
(In reply to Sierk Bornemann from comment #82) > +1 > > See also the unfortunately closed (why?) bug 89657 and the comments and > discussion there. The whole situation is still unacceptable and actually > unreasonable, especially for the average user. We can do better. Just to be clear, I have no special influence on this topic. I am just a volunteer here like everybody else so I don't want to pretend that I have any idea what technical and manpower limits TDF release engineering staff face. TDF release engineering would likely be the people who will implement any solution to this bug so I will trust their judgement as whether my proposal is feasible or not for LibreOffice. @Telesto had asked if I had any experience with this sort of problem. For NeoOffice, even back in 2013 when we first put it in the Mac App Store, paying the cost of increased bandwidth was a no brainer as we had limited time. Plus, since the Mac App Store required one big, complete application, it was easier to just do the same type of installer for our non-Mac App Store builds. Maybe it is the same situation for LibreOffice, maybe not. I don't know.
Test id 1 Test description: Save as not working Result: bcox file extension is wrong
I cannot reproduce this bug on macOS Monterey. I do *not* have Full Disk Access granted to LibreOffice (either in my administrator or non-administrator account) and I tried the following steps: 1. Install the 27 July 2023 nightly build and the French language pack in my non-administrator user's Desktop: https://bugs.documentfoundation.org/show_bug.cgi?id=144053#c33 2. Add a space to LibreOfficeDev.app that I installed in step 1 and launch it. 3. Create new writer file and save to Desktop, Downloads, or Documents folders. No problems encountered. Note: both of the .dmg files that I installed are not codesigned so I will also try the next LibreOffice 7.6 when it is released.
(In reply to Patrick Luby from comment #85) > I cannot reproduce this bug on macOS Monterey. I do *not* have Full Disk > Access granted to LibreOffice (either in my administrator or > non-administrator account) and I tried the following steps: > > 1. Install the 27 July 2023 nightly build and the French language pack in my > non-administrator user's Desktop: > https://bugs.documentfoundation.org/show_bug.cgi?id=144053#c33 > > 2. Add a space to LibreOfficeDev.app that I installed in step 1 and launch > it. > > 3. Create new writer file and save to Desktop, Downloads, or Documents > folders. I retested the above steps with the latest LibreOffice 7.6.0.3 download on macOS Monterey on my Silicon Mac. Still no problems for me. Anyone else still seeing problems with LibreOffice 7.6?
*** Bug 154997 has been marked as a duplicate of this bug. ***
@Bruce: In #154997 you mention updating macOS to 3.3.1 (likely meaning 13.3.1). Could you update to 13.5.1. If you are using language pack, could you remove LibreOffice and re-install without language pack. Is the problem then still reproducible? And if not reproducible and you then install language pack again, does the issue return?
Created attachment 192687 [details] 2024-02-21 macOS 13.6.4 macOS 13.6.4 unable to reproduce. If a needed permission for LibreOffice is missing, the system dialog is shown as expected, requesting the permission. This is worksforme. If you disagree, please provide feedback and steps how to reproduce.