Bug 150372 - Opening dialogs (Character, Paragraph, {Paragraph/Page} Style or Printer Setup) freezes application or blockingly polls (“Please wait for printer connection”) until ~50 s timeout (Windows)
Summary: Opening dialogs (Character, Paragraph, {Paragraph/Page} Style or Printer Setu...
Status: REOPENED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
7.3.5.2 release
Hardware: x86-64 (AMD64) Windows (All)
: low normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2022-08-11 12:11 UTC by newton
Modified: 2025-05-06 20:16 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments
The dump (11.61 MB, application/octet-stream)
2022-09-13 13:15 UTC, newton
Details

Note You need to log in before you can comment on or make changes to this bug.
Description newton 2022-08-11 12:11:45 UTC
Description:
When trying to open the "Character" dialog, the application freezes and it looks like it stopped working. However, after waiting for one minute or so, the dialog actually appears.

This is reproducible at least on LibreOffice Calc, Writer and Impress.


After the dialog had been opened once, it opens 

Steps to Reproduce:
1. Select a word
2. Right-click, click "Character" -> "Character..."


Actual Results:
LibreOffice does not respond (at 0% CPU) for about 1 minute before showing the "Character" dialog

Expected Results:
LibreOffice does not stop to respond. It shows the "Character" dialog either immediately or makes transparent to the user that the dialog is loading.


Reproducible: Always


User Profile Reset: Yes


OpenGL enabled: Yes

Additional Info:
Version: 7.3.5.2 (x64) / LibreOffice Community
Build ID: 184fe81b8c8c30d8b5082578aee2fed2ea847c01
CPU threads: 8; OS: Windows 10.0 Build 19044; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_DE); UI: en-US
Calc: threaded
Comment 1 newton 2022-08-11 12:12:45 UTC
> After the dialog had been opened once, it opens 

I meant to write:

"After the dialog had been opened once, it opens normally."
Comment 2 Rafael Lima 2022-08-15 22:31:49 UTC
I could not reproduce this in

Version: 7.3.5.2 / LibreOffice Community
Build ID: 30(Build:2)
CPU threads: 12; OS: Linux 5.15; UI render: default; VCL: kf5 (cairo+xcb)
Locale: pt-BR (pt_BR.UTF-8); UI: en-US
Ubuntu package version: 1:7.3.5-0ubuntu0.22.04.1
Calc: threaded

The dialog opens very quickly for the first time. Maybe win-only?

Can you try again in safe mode? Next is a link on how to enter safe mode:

https://help.libreoffice.org/latest/en-US/text/shared/01/profile_safe_mode.html
Comment 3 newton 2022-08-15 22:38:07 UTC
Yes, it is reproducible in Safe Mode. (Tested with Writer)
Comment 4 QA Administrators 2022-08-16 04:01:46 UTC Comment hidden (obsolete)
Comment 5 BogdanB 2022-08-16 09:52:04 UTC
Very quick in
Version: 7.5.0.0.alpha0+ (x86) / LibreOffice Community
Build ID: 550392aeb849b326aa0d5d84a0ec1d28d3d42503
CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win
Locale: ro-RO (ro_RO); UI: en-US
Calc: threaded
Comment 6 newton 2022-08-16 13:09:07 UTC
I tested the same version of LibreOffice on another (older, slower) Win10 computer and it worked quite fine.

So the issue is not generic to Win10 but must be something more specific about this one computer.

Any log file I can post or similar?
Comment 7 G 2022-08-31 13:55:45 UTC
Could not reproduce in:

Version: 7.4.0.3 (x64) / LibreOffice Community
Build ID: f85e47c08ddd19c015c0114a68350214f7066f5a
CPU threads: 12; OS: Windows 10.0 Build 19043; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL
Comment 8 vinothanbu3636@gmail.com 2022-09-11 05:45:38 UTC
 step 1:When trying to open the "Character" dialog, the application not freezes   
       and   it looks like it actual  working. However its good.

 not reproduced
 
version:liberofficeDev-7.4.0.0.alpha0_2022-01-23-x86_64.AppImage
NAME="Linux Mint"
VERSION="20.3 (Una)"
its open normal
Comment 9 Timur 2022-09-12 09:25:41 UTC
(In reply to newton from comment #6)
> Any log file I can post or similar?

You may see if there is dump (if procdump closes). Start LO then run procdump from Command Prompt: 
path-to\SYSINTERNALSSUITE\procdump.exe soffice.bin -h path-to\soffice.bin.dmp 

Then it may be analyzed in WinDBG.

But chances of someone looking at not reproducible bug are less than slim.
You may try to uninstall specific fonts if you installed them.
Comment 10 newton 2022-09-13 13:15:13 UTC
Created attachment 182411 [details]
The dump

> path-to\SYSINTERNALSSUITE\procdump.exe soffice.bin -h path-to\soffice.bin.dmp 

Okay, I did and attached it

> You may try to uninstall specific fonts if you installed them.

AFAIK I did not install any fonts. (Any way to find this out?)
Comment 11 Timur 2022-09-13 13:33:18 UTC
May be something with printer. Do you have some installed? Or disconnected?
Comment 12 newton 2022-09-13 13:45:03 UTC
Good hint, this was the culprit!

I removed the printer (it was disconnected, i.e. it's a wifi printer but it is off right now) from printers & scanners and now the character dialog opens as usual.

So, I guess this is a driver issue(?). But if it is possible for some system API that accesses or searches for a printer to timeout like that, maybe this is something that can be taken into account, i.e. do not block the UI/main thread while waiting for a response.
Comment 13 Timur 2022-09-13 13:53:58 UTC
Hi Mike. Since you already was at bug 42673, can you comment on this one?
Should it be marked duplicate or kept separate or just closed?
Comment 14 Rahamanshariff A 2023-02-01 06:19:13 UTC
1-step followed 

   1. Select a word
   2. Right-click, click "Character" -> "Character..."

2-Environment

   os windows 10, 8gp ram,intel i3,64bit

3-Result 

   bug not produce

4-status
   unconfirmed
Comment 15 QA Administrators 2023-08-01 03:16:45 UTC Comment hidden (obsolete)
Comment 16 newton 2023-08-01 10:31:28 UTC
Right, to summarize:

The issue has been reproduced on different computers (all running Windows 10, though). 

Timur suggested it might have something to do with the printer. I can reproduce this:

1. The issue only appears when the wifi printer is OFF, no issue when it is ON and connected.

2. When the printer is removed altogether from printers & scanners, the issue also disappears.

I have an EPSON ET-3750 printer. Whether the issue is reproducible with any other (wifi) printers is unknown.
Comment 17 wjsim 2024-03-11 17:23:33 UTC
I can not reproduce the bug in

Version: 24.2.1.2 (X86_64) / LibreOffice Community
Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac
CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded


Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: 6a064b1967e06e40be40817deff99d00c1a8554f
CPU threads: 16; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: CL threaded
Comment 18 Armondo Lopez 2024-04-11 01:43:44 UTC
I was unable to reproduce the same behavior in

Version: 24.8.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: a2265e8faa099d9652efd12392c2877c2df1d1eb
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

or 

Version: 24.2.1.2 (X86_64) / LibreOffice Community
Build ID: db4def46b0453cc22e2d0305797cf981b68ef5ac
CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: default; VCL: win
Locale: en-US (en_US); UI: en-US
Calc: threaded

I'm also running Windows 10.
Comment 19 Mike Kaganski 2024-11-02 16:56:57 UTC
Comments 12 and 16 makes it clear that it's the duplicate.

*** This bug has been marked as a duplicate of bug 42673 ***
Comment 20 Philippe Cloutier 2025-05-04 16:28:17 UTC
Mike, ticket #42673 is about opening files. The issue this tracks is about opening *the Character dialog* (note that in any case, a user working around a bug does not constitute resolution of that bug).
Comment 21 Philippe Cloutier 2025-05-05 13:37:07 UTC
I get a similar behavior with:
Version: 25.2.3.2 (X86_64) / LibreOffice Community
Build ID: bbb074479178df812d175f709636b368952c2ce3
CPU threads: 8; OS: Windows 11 X86_64 (10.0 build 26100); UI render: Skia/Raster; VCL: win
Locale: fr-CA (fr_CA); UI: fr-FR
Calc: threaded

However, the application does not really hang; it tries to connect to an unreachable printer. After ~3 s, a dialog with the message "Attendez la connexion à l'imprimante ou annulez la connexion" (“Please wait for printer connection or cancel connection”) is displayed until a timeout or a manual cancellation. The timeout happens between 49 and 51 s (presumably, precisely 50 s after polling begins).

I get that behavior with both Writer and Calc, but there are several conditions.

One way to reproduce is to set the default printer to an unreachable printer using Microsoft's Universal Printer Driver (Unidrv). The printer can become unreachable if the PC is on a different LAN than the printer's.

1. Set an unreachable printer as default
2. Create a new document in Writer or Calc
3. Open the Character, Paragraph, Paragraph Style, Page Style or Printer Setup (Printer Settings…) dialog

Once such a poll has timed out, no such poll will happen until LibreOffice is completely closed. Closing the application is not enough (keeping just Calc open is enough to prevent Writer from reproducing).

Therefore, a more precise reproduction method would be, for example:
1. Set an unreachable printer as default
2. Restart the Windows session
3. Run swriter.exe
4. Press Alt+Shift+P
Comment 22 Mike Kaganski 2025-05-06 03:30:12 UTC
(In reply to Philippe Cloutier from comment #20)

If you are going to take the issue(s) and fix them, you are welcome to re-classify them as you feel best for yuor work. Otherwise, you need very strong reasons to change what I did with knowledge how the code works. Currently all recent changes look to me like a noise and clueless vandalising. But I won't start edit wars.
Comment 23 Philippe Cloutier 2025-05-06 17:50:36 UTC
Mike, you did not do this ticket. All you did is you managed to erroneously mark it as resolved for months, claiming it duplicates a ticket reporting different symptoms in a different component, lost the See Also field and managed to insult most of its drivers. We do not need "knowledge how the code works" to triage the ITS, nor lessons from someone clueless about respecting its colleagues.
If you think this is nothing but a noisy duplicate, you are welcome to unsubscribe yourself.

newton@westnordost.de: Do you still experience this with LO 25.2? If so, do you also experience this in the other dialogs mentioned in comment #21 point 3?
Comment 24 newton 2025-05-06 18:12:19 UTC
I switched to Fedora Linux in the meantime, on which I don't observe this issue anymore.

I can confirm what Philippe Cloutier wrote in comment #21:

Since the issue was first reported, LibreOffice behavior in current versions changed from not responding at all to displaying a dialog on startup that states something along the lines of "Waiting for printer" or similar.
This dialog can be dismissed by pressing "Cancel" and LibreOffice will start as normal.
Comment 25 Philippe Cloutier 2025-05-06 18:21:34 UTC
Thank you very much for your quick reply newton@westnordost.de
Since you are no longer affected, would you mind relinquishing parenthood of this ticket? Unless you say the current characterization is exhaustive, I would adopt it and widen its scope to include:
1. the other dialogs I mentioned
2. Windows 11.
Comment 26 newton 2025-05-06 19:17:40 UTC
I don't mind. Do I have to do anything for that to happen?
Comment 27 Philippe Cloutier 2025-05-06 20:16:22 UTC
Oh, sorry, I did not mean anything formal. Thank you, there is nothing more to do, no.


I retitle this to reflect more (perhaps all) dialogs which are affected. I also replaced the "Win10" precision with just "Windows", since:
1. Windows 11 is affected.
2. 
 1. We have little evidence that this does not affect Windows 8
 2. and reports in the related #42673 that Windows 8 and even 7 are affected which might apply to this bug as well.
 3. Windows 10 and 11 are the only (non-server) Windows versions which really matter at this point.

Timur: I am removing "RegeneratePrintDeviceCapabilities" from the title, not because I deny its relevance, but because:
1. It is making the title *really* long at this point.
2. I have no idea what it means, and assume that is the case for the vast majority of contributors.
If you feel RegeneratePrintDeviceCapabilities is important here, feel free to comment with a minimal description of what is it and how it matters.