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
> After the dialog had been opened once, it opens I meant to write: "After the dialog had been opened once, it opens normally."
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
Yes, it is reproducible in Safe Mode. (Tested with Writer)
[Automated Action] NeedInfo-To-Unconfirmed
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
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?
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
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
(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.
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?)
May be something with printer. Do you have some installed? Or disconnected?
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.
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?
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
Dear newton, This bug has been in NEEDINFO status with no change for at least 6 months. Please provide the requested information as soon as possible and mark the bug as UNCONFIRMED. Due to regular bug tracker maintenance, if the bug is still in NEEDINFO status with no change in 30 days the QA team will close the bug as INSUFFICIENTDATA due to lack of needed information. For more information about our NEEDINFO policy please read the wiki located here: https://wiki.documentfoundation.org/QA/Bugzilla/Fields/Status/NEEDINFO If you have already provided the requested information, please mark the bug as UNCONFIRMED so that the QA team knows that the bug is ready to be confirmed. Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-NeedInfo-Ping
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.
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
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.
Comments 12 and 16 makes it clear that it's the duplicate. *** This bug has been marked as a duplicate of bug 42673 ***
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).
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
(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.
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?
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.
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.
I don't mind. Do I have to do anything for that to happen?
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.
(In reply to Philippe Cloutier from comment #23) > 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. The dialog delay is described in https://bz.apache.org/ooo/show_bug.cgi?id=34140#c40 and also mentioned in bug 42673 comment 18 The component is not different, the delay has always been seen in every application. Even if closed, this report is not going anywhere and can be rechecked when bug 42673 is fixed. Mike's decision to close is based on the assumption that the underlying code path is the same and fixing it will make all these delays go away. *** This bug has been marked as a duplicate of bug 42673 ***
(In reply to Buovjaga from comment #28) > (In reply to Philippe Cloutier from comment #23) > > […] > > The dialog delay is described in > https://bz.apache.org/ooo/show_bug.cgi?id=34140#c40 and also mentioned in > bug 42673 comment 18 Note that OOo Bugzilla is basically no longer accessible. The mention in #42673 is not reflected in the ticket's description. > The component is not different, the delay has always been seen in every > application. It is. Report #42673 is about Component Calc. > Mike's decision to close is based on the assumption that > the underlying code path is the same and fixing it will make all these > delays go away. Which might be right, but regardless of whether these 2 tickets report symptoms of the same "technical bug", they are not duplicates (at least currently).
(In reply to Philippe Cloutier from comment #29) > (In reply to Buovjaga from comment #28) > > Mike's decision to close is based on the assumption that > > the underlying code path is the same and fixing it will make all these > > delays go away. > > Which might be right, but regardless of whether these 2 tickets report > symptoms of the same "technical bug", they are not duplicates (at least > currently). What you describe is a duplicate. In any case, this report does not vanish when closed, duplicates can and should be re-tested after a fix, if there is suspicion of remaining issues. Please don't change the status until bug 42673 has been fixed. *** This bug has been marked as a duplicate of bug 42673 ***
(In reply to Buovjaga from comment #30) > (In reply to Philippe Cloutier from comment #29) > > (In reply to Buovjaga from comment #28) > > > […] > > > > Which might be right, but regardless of whether these 2 tickets report > > symptoms of the same "technical bug", they are not duplicates (at least > > currently). > > What you describe is a duplicate. No, what I described is 2 tickets. > In any case, this report does not vanish > when closed, duplicates can and should be re-tested after a fix, if there is > suspicion of remaining issues. It is unclear what you mean by "this report does not vanish when closed", but duplicates cannot be "re-tested", no. Thank you for refraining from marking issues as resolved until they have been.
(In reply to Philippe Cloutier from comment #31) > (In reply to Buovjaga from comment #30) > > In any case, this report does not vanish > > when closed, duplicates can and should be re-tested after a fix, if there is > > suspicion of remaining issues. > > It is unclear what you mean by "this report does not vanish when closed", > but duplicates cannot be "re-tested", no. What is unclear about it? I mean it can always be revisited. Why do you claim duplicates could not be re-tested, it doesn't make any sense to me? > Thank you for refraining from marking issues as resolved until they have > been. Again, this does not make sense. If you continue to change the status, I will ask for permission to ban you from the bug tracker. *** This bug has been marked as a duplicate of bug 42673 ***
(In reply to Buovjaga from comment #32) > (In reply to Philippe Cloutier from comment #31) > > (In reply to Buovjaga from comment #30) > > > In any case, this report does not vanish > > > when closed, duplicates can and should be re-tested after a fix, if there is > > > suspicion of remaining issues. > > > > It is unclear what you mean by "this report does not vanish when closed", > > but duplicates cannot be "re-tested", no. > > What is unclear about it? It is unclear what you mean by "closing a report". > Why do you claim duplicates could not be re-tested, it doesn't make any sense to me? A duplicate is just a ticket; it cannot be tested (or re-tested). One could re-test whether the issue persists, but what you're suggesting would be a waste of time. We don't mark tickets as duplicates just because we speculate solving one issue would also solve the other. > > Thank you for refraining from marking issues as resolved until they have > > been. > > Again, this does not make sense. If you don't understand why a ticket's Status field should match the issue’s actual status, thank you for letting others take care of triaging. I adopted this ticket and am already taking care of its triage. If you mark this as a duplicate of a ticket which does not track the symptoms this one does and without a matching component a single more time without asking for my permission, I will get your triaging permissions on this ITS revoked.
(In reply to Philippe Cloutier from comment #33) > (In reply to Buovjaga from comment #32) > > (In reply to Philippe Cloutier from comment #31) > > > (In reply to Buovjaga from comment #30) > > > > In any case, this report does not vanish > > > > when closed, duplicates can and should be re-tested after a fix, if there is > > > > suspicion of remaining issues. > > > > > > It is unclear what you mean by "this report does not vanish when closed", > > > but duplicates cannot be "re-tested", no. > > > > What is unclear about it? > > It is unclear what you mean by "closing a report". Changing the status to resolved or closed. > > Why do you claim duplicates could not be re-tested, it doesn't make any sense to me? > > A duplicate is just a ticket; it cannot be tested (or re-tested). One could > re-test whether the issue persists, but what you're suggesting would be a > waste of time. We don't mark tickets as duplicates just because we speculate > solving one issue would also solve the other. I don't know what you mean by "we", but are you advocating for only closing reports as duplicates when the issue has been fixed? If so, that's not the practice in our bug tracker. The idea behind closing reports as duplicates "early" is to reduce the sprawl of information and to increase focus.
(In reply to Buovjaga from comment #34) > (In reply to Philippe Cloutier from comment #33) > > (In reply to Buovjaga from comment #32) > > > (In reply to Philippe Cloutier from comment #31) > > > > (In reply to Buovjaga from comment #30) > > > > > In any case, this report does not vanish > > > > > when closed, duplicates can and should be re-tested after a fix, if there is > > > > > suspicion of remaining issues. > > > > > > > > It is unclear what you mean by "this report does not vanish when closed", > > > > but duplicates cannot be "re-tested", no. > > > > > > What is unclear about it? > > > > It is unclear what you mean by "closing a report". > > Changing the status to resolved or closed. It's unclear how a report could be closed, but there is no such status. > > > Why do you claim duplicates could not be re-tested, it doesn't make any sense to me? > > > > A duplicate is just a ticket; it cannot be tested (or re-tested). One could > > re-test whether the issue persists, but what you're suggesting would be a > > waste of time. We don't mark tickets as duplicates just because we speculate > > solving one issue would also solve the other. > > I don't know what you mean by "we", but are you advocating for only closing > reports as duplicates when the issue has been fixed? Of course not. Basically, all I am saying is: A. We (software developers) do not mark issues as resolved until we have good reason to believe that they are. B. Duplicates must have overlapping descriptions. For example, if we have 3 tickets: 1. Fails to install on macOS 2. Fails to install on GNU/Linux 3. Fails to install …then #1 is not a duplicate of #2 and #2 is not a duplicate of #1. They *may* both be duplicates of #3, though, if the component of #3 includes the components of the others and the platform of #3 includes the platforms of the others. And #2 can *become* a duplicate of #1 if #1 is widened to encompass more than macOS. (This comment and any other from myself on this ticket is offered under the terms of CC0 1.0.)
(In reply to Philippe Cloutier from comment #35) > (In reply to Buovjaga from comment #34) > > (In reply to Philippe Cloutier from comment #33) > > > (In reply to Buovjaga from comment #32) > > > > (In reply to Philippe Cloutier from comment #31) > > > > > (In reply to Buovjaga from comment #30) > > > > > > In any case, this report does not vanish > > > > > > when closed, duplicates can and should be re-tested after a fix, if there is > > > > > > suspicion of remaining issues. > > > > > > > > > > It is unclear what you mean by "this report does not vanish when closed", > > > > > but duplicates cannot be "re-tested", no. > > > > > > > > What is unclear about it? > > > > > > It is unclear what you mean by "closing a report". > > > > Changing the status to resolved or closed. > > It's unclear how a report could be closed, but there is no such status. If you click the "Status" link next to the status selection drop down, you are taken to a help page: https://bugs.documentfoundation.org/page.cgi?id=fields.html#bug_status Under the section "Closed Bugs" you will find an explanation. In addition to the default RESOLVED and VERIFIED closed statuses, TDF Bugzilla has an additional, literal CLOSED status, which can be accessed after a report has been closed as RESOLVED. In practice at the moment, the difference is it has anti-spam properties: when a report is CLOSED, anyone posting a link to it will get banned. So we use it for reports that attract automated spam (even though the status existed in the tracker before this use).
Ah, sorry (I guess🤨) and thanks Buovjaga The CLOSED status is confusing enough that I recommended to discard it (in Redmine #3845). Meanwhile, whatever "closed" means, technically, changing the status to CLOSED does not close a report, since tickets with status RESOLVED are already closed.
t-mor@gmx.de: Why did you remove the highly related ticket #42673 from See Also?