Bug 165535 - Opening a LibreOffice file from OneNote takes very long time after upgrading to LO 25.2.1.2
Summary: Opening a LibreOffice file from OneNote takes very long time after upgrading ...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
25.2.1.2 release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisectNotNeeded, regression
Depends on:
Blocks:
 
Reported: 2025-03-02 12:15 UTC by Peter M
Modified: 2025-09-04 22:59 UTC (History)
2 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 Peter M 2025-03-02 12:15:34 UTC
Description:
I've been using OneNote application from Microsoft for years (available as a part of Microsoft 365 or as a free app). It's an app for taking notes, making pictures, storing documents, etc. As a part of my daily workflow, I have attached several ods files directly to my notes. I read and edit them frequently by simply double-clicking them, when LibreOffice opens the file instantly. 

This has worked fine until yesterday with LO 24.2.x (I don't remember the exact version). After I upgraded to LO 25.2.1.2, this takes exactly 120 seconds until LO is open. OneNote remains frozen during that time.

Steps to Reproduce:
1. Create a new ODS file in LO, fill the A1 cell with 123, and save it to some folder, e.g. C:\docs\test.ods.
2. Open OneNote application, create a new page and attach this file to the page.
3. Double-click the document icon in the page.

Actual Results:
OneNote freezes for 120s and after that LO is displayed with the document loaded.

Expected Results:
LO should be displayed instantly with the document loaded.


Reproducible: Always


User Profile Reset: Yes

Additional Info:
Other document types are opened instantly from OneNote: PDF, XLSX, ...

Opening the C:\docs\test.ods from the file explorer works fine. If I double-click it, LO opens instantly.

When I double-click the file in OneNote, I can see the two processes created immediately in the Task manager: soffice.bin and soffice.exe. After 120s, they are replaced by a single soffice.bin process.

I tried unchecking "Load printer configuration with document" as suggested at 
https://www.reddit.com/r/libreoffice/comments/upf8nw/fixed_opening_documents_too_slow/
or
https://ask.libreoffice.org/t/libre-office-slow-opening-a-document-hangs-for-45-to-60-seconds-for-writer-when-connected-to-the-internet/82665/17
to no avail.


Version: 25.2.1.2 (X86_64) / LibreOffice Community
Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49
CPU threads: 16; OS: Windows 11 X86_64 (10.0 build 26100); UI render: default; VCL: win
Locale: sk-SK (sk_SK); UI: sk-SK
Calc: threaded
Comment 1 Peter M 2025-03-02 12:24:50 UTC
This problem applies to any OL file, e.g., ODT, not just to ODS files.
Comment 2 Buovjaga 2025-03-02 13:03:18 UTC
As it is probably very rare for QA or devs to have access to OneNote, you could try bibisecting the issue with the win64-25.2 repository (although it could be a 24.8 bug as you say you jumped from 24.2 to 25.2).

https://wiki.documentfoundation.org/QA/Bibisect
https://wiki.documentfoundation.org/QA/Bibisect/Windows
https://wiki.documentfoundation.org/QA/Bibisect/Bibisecting_tutorial
Comment 3 Brandon H. 2025-03-29 00:48:24 UTC
I am able to reproduce this issue on version 25.2.2.2, but I haven't bibisected it. 

Version: 25.2.2.2 (X86_64) / LibreOffice Community
Build ID: 7370d4be9e3cf6031a51beef54ff3bda878e3fac
CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 22631); UI render: Skia/Raster; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded
Comment 4 Juan Q. 2025-04-07 10:22:36 UTC
Able to reproduce using 

Version: 25.2.1.2 (X86_64) / LibreOffice Community
Build ID: d3abf4aee5fd705e4a92bba33a32f40bc4e56f49
CPU threads: 12; OS: Windows 10 X86_64 (10.0 build 19045); UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 5 Buovjaga 2025-04-07 12:41:32 UTC
A quick note: I did not really consider what it takes to bibisect this: one would have to temporarily associate .ods files with the instdir/program/soffice in the win64-25.2 bibisect repository specifically. Otherwise OneNote will open the wrong LibreOffice. So I guess one would have to go to the file association settings in Windows and change that.
Comment 6 Peter M 2025-04-12 17:12:16 UTC
I wasn't able to bibisect, as on each try I had to change the OS file associations and even then they were sometimes ignored by OneNote and the document was open in Excel.

But I have additional info. I managed to retrieve the command line parameters of these two LibreOffice processes from the Task manager (in Details view, right-click a process, Create memory dump file, then open the dmp file in Visual Studio 2022).

When I double-click an .ods file in Windows file explorer, all works correctly (it opens immediately) and the parameters are:

Process Name:	C:\Program Files\LibreOffice\program\soffice.exe -o "C:\Users\USER\OneDrive\Desktop\Test.ods"
Process Name:	C:\Program Files\LibreOffice\program\soffice.bin "-o" "C:\Users\USER\OneDrive\Desktop\Test.ods" "-env:OOO_CWD=2C:\\Users\\USER\\OneDrive\\Desktop"

But when I double-click the file in OneNote, the parameters are:

Process Name:	C:\Program Files\LibreOffice\program\soffice.exe --nodefault --nologo -Embedding
Process Name:	C:\Program Files\LibreOffice\program\soffice.bin "--nodefault" "--nologo" "-Embedding" "-env:OOO_CWD=2C:\\WINDOWS\\system32"

After 120sec, the file is open.

It seems like this -Embedding parameter causes problems. According to https://help.libreoffice.org/latest/en-US/text/shared/guide/start_parameters.html, this parameter is COM+ related; Windows only.

I created a testing .bat file with this content:

"C:\Program Files\LibreOffice\program\soffice.exe" --nodefault --nologo -Embedding
pause

It starts these two processes and nothing happens, they run forever and I need to kill them.
Comment 7 Noel Grandin 2025-04-17 13:04:51 UTC
The "-Embedding" arg has been ignored for a very long time.

But what it does cause, is LibreOffice tries to print out a message telling you that the argument is deprecated and should not be used anymore.

I am guessing that, if there is no console attached to the process, then trying to print out that message will block the process forever.

The relevant source code is in:

desktop/source/app/cmdlineargs.cxx:442:            /* fdo#57203 ignore -Embedding on Windows
desktop/source/app/cmdlineargs.cxx:445:            else if ( oArg == "Embedding" )
desktop/source/app/cmdlinehelp.cxx:184:        "   -Embedding          Ignored (COM+ related; Windows only).                   \n"


if anyone wants to hazard some kind of workaround.
Comment 8 ayoshida 2025-09-03 01:15:42 UTC
Please allow me to jump in.  I am a LO user in Japan, and I have a similar issue with LO 25.2.5 (Japanese) and finally arrived at this thread.  I think my issue is the same one as discussed in this thread.   Here is my problem:

Step1: Create a odx document fine (x = p, s, or t) on Windows11.
Step2: Attach the file to a note page in OneNote (Desktop).
Step3: Try to open the attached odx file by double-clicking the file icon in the OneNote note page.
 
What happens is:
If using LO 25.2.5 to open the file, it takes 120 seconds until LO program appears on the screen and open the document.
If using an older LO 24.8.7, it takes just 10 seconds, which looks normal.
If using the newest version LO 25.8.1, it takes 120 seconds as well.

So, I think until version 24.8, opening odx files attached to OneNote worked fine, but after version 25.x, it takes very long time (120 s) and even with the newest version 25.8, this issue remains.

If my issue is consistent with the topic discussed in this thread, which I hope, please keep taking care of it.

Thank you
Comment 9 Buovjaga 2025-09-03 06:55:21 UTC
As we have code pointers in comment 7, let's remove the request to bibisect.
Comment 10 ayoshida 2025-09-04 02:09:48 UTC
(In reply to Buovjaga from comment #9)
> As we have code pointers in comment 7, let's remove the request to bibisect.

Hi, may I understand that this issue is already recognized and its bug-fixing process is underway?

Thank you.
Comment 11 Buovjaga 2025-09-04 08:55:06 UTC
(In reply to ayoshida from comment #10)
> (In reply to Buovjaga from comment #9)
> > As we have code pointers in comment 7, let's remove the request to bibisect.
> 
> Hi, may I understand that this issue is already recognized and its
> bug-fixing process is underway?

It has been recognised, but the fixing is not underway.
Comment 12 ayoshida 2025-09-04 22:59:56 UTC
(In reply to Buovjaga from comment #11)
> (In reply to ayoshida from comment #10)
> > (In reply to Buovjaga from comment #9)
> > > As we have code pointers in comment 7, let's remove the request to bibisect.
> > 
> > Hi, may I understand that this issue is already recognized and its
> > bug-fixing process is underway?
> 
> It has been recognised, but the fixing is not underway.

Thank you.  I look forward to getting this issue fixed in the future releases.