Bug 166898 - Writer unresponsive for 20 seconds when saving a DOCX file (or saving it as ODT)
Summary: Writer unresponsive for 20 seconds when saving a DOCX file (or saving it as ODT)
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Writer (show other bugs)
Version:
(earliest affected)
4.2.0.4 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: filter:docx, filter:odt
Depends on:
Blocks: Performance
  Show dependency tree / graph
 
Reported: 2025-06-07 18:50 UTC by Telesto
Modified: 2026-01-25 16:55 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:

Attachments
Some MS Word OLE embeddings (204.30 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2025-06-07 20:04 UTC, Mike Kaganski 		Details
Some Acrobat Reader OLE objects (958.77 KB, application/vnd.openxmlformats-officedocument.wordprocessingml.document)
2025-06-07 20:33 UTC, Mike Kaganski 		Details
View All Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2025-06-07 18:50:43 UTC 
Description:
Writer unresponsive for 20 seconds when saving a DOCX file (or saving it as ODT)

Steps to Reproduce:
1. Open http://oval.mitre.org/language/version5.10.1/OVAL_Unix_Component_Specification.04-04-2012.docx
2. Press Save

Actual Results:
Writer doesn't respond for 20 seconds or so
* no CPU hammering
* no progress bar (in case of DOCX)

Follow up save is fast. File -> Reload and it's slow again

Expected Results:
* At minimum a progress bar for the DOCX case.
* Ideally some speed-up


Reproducible: Always


User Profile Reset: No

Additional Info:
Version: 25.8.0.0.alpha1+ (X86_64) / LibreOffice Community
Build ID: 17e8dbead42e2d4b55815b1b7b2846b03d62a15d
CPU threads: 4; OS: Windows 10 X86_64 (build 19045); UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL threaded

and in
Version: 7.0.7.0.0+ (x64)
Build ID: 626ea4e62a3e5005fe9825923a1c0c5bdb61cc08
CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win
Locale: nl-NL (nl_NL); UI: en-US
Calc: CL


also in
Versie: 4.4.7.2 
Build ID: f3153a8b245191196a4b6b9abd1d0da16eead600
Locale: nl_NL

and in
Versie: 4.2.0.4 
Build ID: 05dceb5d363845f2cf968344d7adab8dcfb2ba71
Comment 1 Mike Kaganski 2025-06-07 19:39:50 UTC 
Repro - but only when Visio is installed on the system. Windows-only.

The reason is, that during that period, for each of the 28 embedded objects, an instance of Visio starts, opens that object, and reports some information back. That takes time; it's unclear why do we really need to activate all OLE objects now - can't we just re-use the information that we already have?
Comment 2 Mike Kaganski 2025-06-07 20:04:37 UTC 
Created attachment 201129 [details]
Some MS Word OLE embeddings

This sample has the same problem, but depends on more easily available MS Word.
Comment 3 Mike Kaganski 2025-06-07 20:33:05 UTC 
Created attachment 201130 [details]
Some Acrobat Reader OLE objects

And finally - the same problem using Acrobat Reader (i.e., a freeware, so anyone can install it to test).
Comment 4 Mike Kaganski 2025-06-07 20:38:58 UTC 
An interesting detail is: the slow save is only when opening DOCX. If you open the ODT saved from that DOCX, or a DOC from that DOCX - their save is instant. So definitely, there's some sub-optimal processing, likely in the DOCX *import* stage (which results in slow save not only back to DOCX, but to any formats, this time).