On both OpenOffice and LibreOffice 7.4 current release, using Copy causes program to freeze. This started when I "upgraded" from Windows 10 to Windows 11. It freezes no matter whether I right-click/Copy or whether I choose it from the Edit Menu. Pasting from other programs still works, though.
Please test in safe mode, Menu/Help/Restart in Safe Mode
I tried restarting in safe mode. The problem is still present: using Copy from either the Edit menu or from right-click/Copy causes the program to freeze up. This is some kind of conflict with Windows 11 as the problem started when I made that OS upgrade. I don't have the problem on a version of Apache Open Office on my laptop running Windows 10 (a corporate machine, I don't have admin rights on it).
Please test if modifying Skya status has some effect. Menu/Tools/Options/View
There was no change in the "copy" problem. I unchecked "Use Skia for all rendering" and restarted LO. No change. I checked "Use Skia..." and restarted, and no change.
Can you test if it is enable 'History clipboard' https://www.bing.com/search?q=history+clipboard+windows+10&form=WNSGPH&qs=UT&cvid=d249330764c14d6fa33d2fd2b1096936&pq=history+clipbo&cc=ES&setlang=es-ES&nclid=818D6C6EB1B769DDDF3D895E74653213&ts=1674416265366&wsso=Moderate Do you have any clipboard manager running?
I did have Windows Clipboard History turned on. No other clipboard manager is being used. I turned it off and restarted the PC. The Copy problem is still present. Good idea, though!
I can't find any other similar report, and I don't have win 11 test. Let's see if someone else can test. Meanwhile, you can try to see in the Task manager / Details, sorting CPU (inverse) if there is some program with a high usage when this happens.
Thanks for looking at this. When I have Task Manager open and try to use Copy in LO Calc, when LO Calc freezes the LibreOffice CPU usage goes to 26%, and its memory usage progressively increases from 204 MB to over 1,300 MB within about 30 seconds. I closed the program as it started taking over the Memory!
No other program increases CPU or memory usage when this problem occurs.
Can you try to uninstall, and rename/delete the profile (https://wiki.documentfoundation.org/UserProfile), and reinstall again?
The problem persisted when I entered safe mode previously. So according to the UserProfile Wiki, the profile is not problem, right?
I tried the manual procedure, too, renaming the user file user-old and restarting the program to create a new user file. The copy problem in Calc persists. That's with it using .ods .xls and .xlsx format files, although once in a while the program doesn't crash the first time I try using Copy.
I renamed the User-old, uninstalled LibreOffice 7.4.4.2 and installed 7.3.7.2. The Calc Copy problem persists in crashing the program. I've reverted to my old profile now.
On Windows 11 1. Created a new Calc spreadsheet 2. Copied cell A1 No freeze. Memory use did not increase at all. Version: 7.4.5.0.0+ (x64) / LibreOffice Community Build ID: 610880abd9f3be00451db51f05b7f4772c389b7a CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-US (en_FI); UI: en-US Calc: threaded
(In reply to Buovjaga from comment #14) > On Windows 11 > > 1. Created a new Calc spreadsheet > 2. Copied cell A1 > > No freeze. Memory use did not increase at all. > > Version: 7.4.5.0.0+ (x64) / LibreOffice Community > Build ID: 610880abd9f3be00451db51f05b7f4772c389b7a > CPU threads: 2; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: > win > Locale: en-US (en_FI); UI: en-US > Calc: threaded I'm not a developer or a programmer. Why does the information you included say Windows 10.0 instead of Windows 11?
(In reply to ericbresslermd from comment #15) > I'm not a developer or a programmer. Why does the information you included > say Windows 10.0 instead of Windows 11? Because Microsoft decided this is the way things are. You can see it in your Help - About window and by the way, you should always copy the information from there into your bug reports.
Here is my PC's info. As yo ucan see, it says Windows 11 Pro. Device name DESKTOP-LADH9BG Processor Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz 2.90 GHz Installed RAM 16.0 GB (15.7 GB usable) Device ID 13BD424F-635E-46AF-B83B-8771CA06B7DB Product ID 00330-52927-20105-AAOEM System type 64-bit operating system, x64-based processor Pen and touch No pen or touch input is available for this display Edition Windows 11 Pro Version 22H2 Installed on 11/15/2022 OS build 22621.1105 Experience Windows Feature Experience Pack 1000.22638.1000.0
(In reply to ericbresslermd from comment #17) > Here is my PC's info. As yo ucan see, it says Windows 11 Pro. > > Device name DESKTOP-LADH9BG > Processor Intel(R) Core(TM) i5-9400 CPU @ 2.90GHz 2.90 GHz > Installed RAM 16.0 GB (15.7 GB usable) > Device ID 13BD424F-635E-46AF-B83B-8771CA06B7DB > Product ID 00330-52927-20105-AAOEM > System type 64-bit operating system, x64-based processor > Pen and touch No pen or touch input is available for this display > > Edition Windows 11 Pro > Version 22H2 > Installed on 11/15/2022 > OS build 22621.1105 > Experience Windows Feature Experience Pack 1000.22638.1000.0 No, that's not what I meant. Help - About *in LibreOffice*. Click the copy button and do not close the window before pasting.
Version: 7.3.7.2 (x64) / LibreOffice Community Build ID: e114eadc50a9ff8d8c8a0567d6da8f454beeb84f CPU threads: 6; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL
1.Steps followed to reproduce i. Created a new Calc spreadsheet ii. Copied cell A1 No freeze. Memory use did not increase at all. 2.Environment: os windows 11,RAM 8GB,ROM 512,version 7.6.0.0 alpha0+(*86)/Libraoffice 3.Result:Bug not reproduced 4.Status:unconfirmend
Thanks, Karthikeyan. When I follow the same procedure, my LibreOffice freezes every time. It doesn't matter whether there is anything in the A1 cell or not, or whether the new spreadsheet has been saved or not.
The program also freezes when I try to use the Cut commands from both the Edit Menu and from right-click/Cut.
In Windows 10, in current LO (7.4.7) and previous LO (7.4.6). When copying from a calc cell to the search box in another spreedsheet, Calc is completely frozen (I have to stop it with ctl-alt-del). Happened 3 times thus far during about 1 month. I open usually many spreedsheets but didn't keep a log of how many. Last time, 6 files. Running at the same time (I don't know how to get the crash report): seamonkey, firefox and chrome, notepad++, old Forte Agent, command prompt.
(In reply to Denis from comment #23) > In Windows 10, in current LO (7.4.7) and previous LO (7.4.6). When copying > from a calc cell to the search box in another spreedsheet, Calc is > completely frozen (I have to stop it with ctl-alt-del). Happened 3 times > thus far during about 1 month. I open usually many spreedsheets but didn't > keep a log of how many. Last time, 6 files. > > Running at the same time (I don't know how to get the crash report): > seamonkey, firefox and chrome, notepad++, old Forte Agent, command prompt. Version: 7.4.7.2 (x64) / LibreOffice Community Build ID: 723314e595e8007d3cf785c16538505a1c878ca5 CPU threads: 12; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: fr-CA (fr_CA); UI: fr-FR Calc: threaded
Now with win11 I can't repro. Version: 7.5.3.2 (X86_64) / LibreOffice Community Build ID: 9f56dff12ba03b9acd7730a5a481eea045e468f3 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: es-ES (es_ES); UI: en-US Calc: CL threaded You don't have OpenCL enable, maybe because don't pass the LibreOffice test to enable it. Try to update the driver of video card from the manufacturer.
I think I might have the same problem but on a different configuration. See my bug report for Bug 156290 I found a possible work around that you could try. Try running calc from the command prompt using scalc.exe like I describe in 156290.
Thanks, Barry. Unfortunately I can't run scalc.exe from my command prompt using the text you included in your bug report for https://bugs.documentfoundation.org/show_bug.cgi?id=156290
I can't reproduce this with windows 11 Version: 7.5.4.2 (X86_64) / LibreOffice Community Build ID: 36ccfdc35048b057fd9854c757a8b67ec53977b6 CPU threads: 8; OS: Windows 10.0 Build 22621; UI render: Skia/Vulkan; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
*** Bug 156500 has been marked as a duplicate of this bug. ***
Thank you. My report 156500 was a duplicate of this. The solution outlined at https://bugs.documentfoundation.org/show_bug.cgi?id=156290 is working for me. I used the simple prompt without defining UserInstallation. My thanks to all who have contributed!
Test repairing LibreOffice installation. https://support.microsoft.com/en-us/windows/uninstall-or-remove-apps-and-programs-in-windows-4b55f974-2cc6-2d2b-d092-5905080eaf98 select repair with right-click, instead uninstall.
I just tried to Repair the installation, but that didn't work to squash the bug.
I had also tried the repair on July 31, and it didn't work.
BTW, there are a lot of resources about "Windows 11 Freezes Randomly", searching in the web.
In bug 156290 comment 3 Eric said: (In reply to ericbresslermd from comment #3) > Using the command prompt with this command as suggested by Barry Kramer did > prevent the hanging from using Copy and Cut on my system. > > "C:\Program Files\LibreOffice\program\scalc.exe" > > The -env:UserInstallation= etc. did not work; fatal error as user > installation could not be completed. Let's set this to new and close the newer one.
*** Bug 156290 has been marked as a duplicate of this bug. ***
I mentioned this in the dev chat and there was a suggestion to install Very Sleepy http://www.codersnotes.com/sleepy/ to grab some stacktraces of the soffice process. For this to work, you need to install the debug build Win-x86@39 from https://dev-builds.libreoffice.org/daily/master/current.html The master build installs separately.
Another comment from the chat: 'shortcuts on Windows may include some "run in compat mode" options - I don't think our installer sets those, but they could e.g. be set by installer by default when detecting some manifest (or its absense); or it could be set by the super-smart system after a crash' So you could right-click the shortcut on the desktop, select Properties and click the Compatibility tab. For me, none of the checkboxes are checked.
(In reply to Buovjaga from comment #37) > I mentioned this in the dev chat and there was a suggestion to install Very > Sleepy http://www.codersnotes.com/sleepy/ to grab some stacktraces of the > soffice process. For this to work, you need to install the debug build > Win-x86@39 from https://dev-builds.libreoffice.org/daily/master/current.html > > The master build installs separately. Another note came up: you don't have to install the debug build as all release builds can get symbols via the symbol server. In Very Sleepy: Tools - Options - Symbol server location, add to the existing text: ;https://dev-downloads.libreoffice.org/symstore/symbols
My system still has this problem. I am a computer engineer by trade and I will try to use these tools to get you the information you need. I am not familiar with them right now so I will need a while to review the documentation to learn exactly how to do this. In the meantime I can confirm that there are no compatibility mode settings applied to the shortcut on my windows system. To reiterate, running calc from the shortcut will demonstrate the hang problem, but running scalc at the command line does not. So I will try to compare the two situations.
(In reply to Barry L. Kramer from Bug 156290 comment #0) > Running Calc from the Windows shortcut: > > ... > > The following is my > workaround for getting Calc to run without crashing: from a CMD prompt: > > C:>"C:\Program Files\LibreOffice\program\scalc.exe" And which shortcut is meant exactly? The direct one for Calc (also running scalc.exe)? Or the generic running soffice.exe? Does a new shortcut created for the executable(s) manually show the same problem?
(In reply to Mike Kaganski from comment #41) > And which shortcut is meant exactly? The direct one for Calc (also running > scalc.exe)? Or the generic running soffice.exe? The one for Calc that was created by the installer in the apps menu. It is located in: C:\ProgramData\Microsoft\Windows\Start Menu\Programs\LibreOffice 7.5 and its target is: "C:\Program Files\LibreOffice\program\scalc.exe" with Start In set to "C:\Program Files\LibreOffice\" For more info, please see my original report as Bug 156290 (now marked as a duplicate... I looked for other reports but did not find one until later.) https://bugs.documentfoundation.org/show_bug.cgi?id=156290 > Does a new shortcut created for the executable(s) manually show the same > problem? Yes. I also tried a different Start In location - still hangs on copy. And I tried using the LibreOffice shortcut then selecting Create: Calc Spreadsheet - still hangs on copy. blk
(In reply to Buovjaga from comment #37) We also have a documentation on producing backtraces on Windows: https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg#Producing_a_mini_dump Having a minidump would definitely help.
Created attachment 189602 [details] Very Sleepy output of soffice.bin (stopped during hang after copy) This is the output of Very Sleepy profile of the soffice.bin process. Started profiling after Calc is running on a blank (new document); stopped after hang that occurred after pressing ^C with default selection (on cell A1). Calc was run from the windows Calc shortcut. Windows version: Edition Windows 11 Home Version 22H2 Installed on 2/22/2023 OS build 22621.2283 Experience Windows Feature Experience Pack 1000.22662.1000.0 Java version 8 update 371 Calc version: Version: 7.5.4.2 (X86_64) / LibreOffice Community Build ID: 36ccfdc35048b057fd9854c757a8b67ec53977b6 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded
Created attachment 189603 [details] Very Sleepy output of soffice.bin (stopped after copy, no hang) This is the same soffice.bin profiling output, except in this case when Calc was invoked from the cmd prompt (scalc). I did the same ^C to copy cell A1, then stopped the profiling, with no hang, since it hangs when run from the windows shortcut but not when invoked using scalc.exe.
Created attachment 189644 [details] output of procdump (In reply to Mike Kaganski from comment #43) > (In reply to Buovjaga from comment #37) ... > Having a minidump would definitely help. Everyone, I was able to get the development tools running, and I do still see this problem on the debug build which is great. I am using the following version of Dev 24: Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: b3fdd999f87312447d03915585812b3a5cd48141 CPU threads: 16; OS: Windows 10.0 Build 22621; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: CL threaded Attached is the output of procdump.exe soffice.bin -h
Created attachment 189646 [details] Very Sleepy output of Dev 24 soffice.bin (stopped during hang after copy) This is the output of the debug version (Dev 24), stopped during hang after Copy cell A1 when Calc is run from the desktop shortcut.
Created attachment 189647 [details] Very Sleepy output of Dev 24 soffice.bin (stopped after successful copy) This is the output of the debug version (Dev 24), stopped after Copy cell A1 worked when Calc is run from the exe (scalc) at the command line (in cmd).
Unfortunately, I don't see a way to use the Very Sleepy results: at least I don't know how to see the *specific* backtrace of every active thread at the moment when the file was generated. The profiling info (the main goal of the Very Sleepy tool) is uninteresting to me; only the traces are, but the traces available in the tool are not bound to the program states, but to function time statistics. The wiki mentioned in comment 43 does not mention any "Very Sleepy"...
(In reply to Mike Kaganski from comment #49) > > The wiki mentioned in comment 43 does not mention any "Very Sleepy"... True. Very Sleepy was mentioned in comment 37 and comment 39. The minidump from the wiki mentioned in comment 43 is in the attachment of comment 46. I think I followed the instructions in the wiki, and the .dmp file can be loaded into WinDbg (X64). This is the first time I'm doing this, so if I made a mistake or if I can do it differently, please let me know. I'd even be willing to use other tools or WinDbg in other ways but I would need some direction as I'm completely unfamiliar with LO except as a user, although I have lots of development experience.
(In reply to Barry L. Kramer from comment #50) > The minidump from the wiki mentioned in comment 43 is in the attachment of > comment 46. Ah! Yes, you are completely correct. I missed that somehow. Do you use some accessibility software?
(In reply to Barry L. Kramer from comment #46) > I am using the following version of Dev 24: > > Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community > Build ID: b3fdd999f87312447d03915585812b3a5cd48141 Is that your own build? I haven't found it in our dailies (the one from Sep 14 there is 4942aa1533af25cf102da7516bd5e521c553aa07, i.e. several commits later, and its binaries aren't accepted to debug this minidump)
I believe that the best would be a minidump for some *release* version - because we have symbols for them on our symbol server. Any local or daily build would have a symbols missing problem...
(In reply to Mike Kaganski from comment #52) > > Is that your own build? I haven't found it in our dailies No, I don't know how to build it yet. I used the link in one of the comments (https://dev-builds.libreoffice.org/daily/master/current.html) and chose "Win-x86_64@tb77-TDF 2023-09-15 05:28:33". I'll try to find a debug version. Do you have a link I should follow? I would be happy to run it again....
(In reply to Barry L. Kramer from comment #54) > Do you have a link I should follow? I would be happy to run it again.... I would be clad if you create a minidump using any release version - the normal one, like 7.5.4.2 that you used in comment 44.
(In reply to Barry L. Kramer from comment #54) > (In reply to Mike Kaganski from comment #52) > > > > Is that your own build? I haven't found it in our dailies > > > No, I don't know how to build it yet. I used the link in one of the comments > (https://dev-builds.libreoffice.org/daily/master/current.html) and chose > "Win-x86_64@tb77-TDF 2023-09-15 05:28:33". I'll try to find a debug > version. Do you have a link I should follow? I would be happy to run it > again.... That's a version *without* debug symbols. The one with debug symbols is Win-x86@39. It can be used with Windbg per https://wiki.documentfoundation.org/How_to_get_a_backtrace_with_WinDbg#First_Time_Setup "Alternatively if you wish to also debug both the standard build and master build (Win-x86@39 tinderbox), paste the following instead" etc.
(In reply to Mike Kaganski from comment #51) > > Do you use some accessibility software? Nice catch, Mike! YES I am, and THAT is a prerequisite condition to the hang. I use Windows Speech Recognition, the windows built-in dictation software. Based on your excellent question, I tested to see if the hang follows any of the related settings and it does. In Settings > Accessibility > Speech (under the heading Interaction), the setting "Windows Speech Recognition", when On causes the hang to appear, and when Off causes it to go away. I observed that after setting it Off, a restart might be required, and when set back On, the hang might not happen on the very first cell copy, but it will in the first few. This accessibility setting, when On, lets the user close or minimize the speech to text input tool which can be launched manually with Windows logo key + H. Whether that is present or not, or used or not, does not seem related. Only the control panel setting is. Hopefully this discovery will allow a developer to reproduce the problem. It certainly explains why it affects so few users.
I can reproduce on Windows 10 (Version 22H2 (OS Build 19045.3448)) as well. At first glance, it looks like Windows Speech Recognition tries to iterate over all of the cells of the table (or maybe "just" over the first 2147483648 ones, since that's the max amount that the 32-bit API allows to return in `CMAccessible::get_accChildCount`, or whatever other limit Windows Speech Recognition or some library underneath have). With a breakpoint in `CMAccessible::get_accChild` [1], I see this getting called e.g. with `varChild.lVal = 1141`, then `varChild.lVal = 1142`, etc. And after letting it run for a while with `varChild.lVal = 3694`, then `varChild.lVal = 3695`,... Backtrace below. I can't see anything obviously wrong on LO side here, it seems to be getting requests via the accessibility API that it is handling correctly. Without knowing any further details on what Windows Speech Recognition is doing here, it's hard to further analyze this and I tend to think that Windows Speech Recognition shouldn't be requesting all of the cells (accessible children of the table). Can you please report this issue to Microsoft as well and report back here if you get any reply from them? Backtrace: 1 CMAccessible::get_accChild MAccessible.cxx 333 0x7fff7ba4b1ac 2 CreateStdAccessibleProxyW OLEACC 0x7fff93119f07 3 UiaReturnRawElementProvider uiautomationcore 0x7fff965938de 4 UiaReturnRawElementProvider uiautomationcore 0x7fff96594211 5 UiaReturnRawElementProvider uiautomationcore 0x7fff965939e8 6 UiaReturnRawElementProvider uiautomationcore 0x7fff96598f40 7 UiaReturnRawElementProvider uiautomationcore 0x7fff9659b407 8 UiaGetReservedMixedAttributeValue uiautomationcore 0x7fff965bb46c 9 DllCanUnloadNow uiautomationcore 0x7fff965760fe 10 UiaClientsAreListening uiautomationcore 0x7fff965aa999 11 UiaGetReservedMixedAttributeValue uiautomationcore 0x7fff965b52e6 12 UiaGetReservedMixedAttributeValue uiautomationcore 0x7fff965b44f1 13 UiaGetReservedMixedAttributeValue uiautomationcore 0x7fff965b3058 14 UiaClientsAreListening uiautomationcore 0x7fff965ab2b8 15 DllCanUnloadNow uiautomationcore 0x7fff965760fe 16 UiaClientsAreListening uiautomationcore 0x7fff965aa999 17 UiaLookupId uiautomationcore 0x7fff9658d91e 18 UiaLookupId uiautomationcore 0x7fff9658d744 19 uiautomationcore 0x7fff96567300 20 uiautomationcore 0x7fff96563c9c 21 DllCanUnloadNow uiautomationcore 0x7fff965760fe 22 DllCanUnloadNow uiautomationcore 0x7fff9657c997 23 DllCanUnloadNow uiautomationcore 0x7fff9657c0e9 24 uiautomationcore 0x7fff9656acf7 25 UiaReturnRawElementProvider uiautomationcore 0x7fff9659db15 26 UiaReturnRawElementProvider uiautomationcore 0x7fff9659d7d7 27 Ordinal2712 USER32 0x7fffade2e062 28 SendMessageTimeoutW USER32 0x7fffade30c93 29 KiUserCallbackDispatcher ntdll 0x7fffaf850cd4 30 NtUserGetMessage win32u 0x7fffad2c1104 31 GetMessageW USER32 0x7fffade31c0e 32 ImplSalYield salinst.cxx 531 0x7fff641c03da 33 WinSalInstance::DoYield salinst.cxx 580 0x7fff641bfe01 34 ImplYield svapp.cxx 377 0x7fff674a7934 35 Application::Yield svapp.cxx 462 0x7fff674ab8a2 36 Application::Execute svapp.cxx 355 0x7fff674a4c5a 37 desktop::Desktop::Main app.cxx 1601 0x7fff7b3c96c2 38 ImplSVMain svmain.cxx 204 0x7fff674bd1bc 39 SVMain svmain.cxx 237 0x7fff674bda22 40 soffice_main sofficemain.cxx 94 0x7fff7b418232 41 sal_main main.c 51 0x7ff787e61013 42 main main.c 49 0x7ff787e6105a 43 invoke_main exe_common.inl 79 0x7ff787e61459 44 __scrt_common_main_seh exe_common.inl 288 0x7ff787e6137e 45 __scrt_common_main exe_common.inl 331 0x7ff787e6123e 46 mainCRTStartup exe_main.cpp 17 0x7ff787e614ce 47 BaseThreadInitThunk KERNEL32 0x7fffae6c7344 48 RtlUserThreadStart ntdll 0x7fffaf8026b1 [1] https://git.libreoffice.org/core/+/b47a69ebee54a4b399c90311e17b994635140002/winaccessibility/source/UAccCOM/MAccessible.cxx#333 Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 6f60670877208612b5ea320b3677480ef6508abb CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_DE); UI: en-US Calc: threaded
Thank you all for identifying this. I turned off the speech recognition program quite a while ago and did not even remember I had enabled it in Settings. My problem is solved. I appreciate all your work on this.
(In reply to Michael Weghorn from comment #58) > At first glance, it looks like Windows Speech Recognition tries to iterate > over all of the cells of the table (or maybe "just" over the first > 2147483648 ones, since that's the max amount that the 32-bit API allows to > return in `CMAccessible::get_accChildCount`, or whatever other limit Windows > Speech Recognition or some library underneath have). > > ... > > I can't see anything obviously wrong on LO side here, it seems to be getting > requests via the accessibility API that it is handling correctly. I /suspect/ that the API [1] assumes (or allows) the get_accChildCount to return a number only reflecting *visible* children. In this case, scrolling would generate EVENT_OBJECT_CREATE and EVENT_OBJECT_DESTROY events. If you create a test program for texting what Excel reports - the number of accessible children, and maybe which are those - I could test locally for you, and report back, to confirm / reject this suspicion. [1] https://learn.microsoft.com/en-us/windows/win32/api/oleacc/nf-oleacc-iaccessible-get_accchildcount
(In reply to Mike Kaganski from comment #60) > I /suspect/ that the API [1] assumes (or allows) the get_accChildCount to > return a number only reflecting *visible* children. In this case, scrolling > would generate EVENT_OBJECT_CREATE and EVENT_OBJECT_DESTROY events. Thanks. I just tested Excel (LTSC 2021) with NVDA's interactive Python console (move mouse over cell, then Insert+Ctrl+Z to open the console) and the result is "interesting". Excel doesn't seem to allow the "usual" way to access the children at all: > >>> mouse.name > '' > >>> mouse.role > <Role.TABLECELL: 29> > >>> mouse.parent > <NVDAObjects.window.excel.ExcelWorksheet object at 0x043BEDD0> > >>> sheet = mouse.parent > >>> sheet.childCount > Traceback (most recent call last): > File "<console>", line 1, in <module> > File "baseObject.pyc", line 62, in __get__ > File "baseObject.pyc", line 168, in _getPropertyViaCache > File "NVDAObjects\__init__.pyc", line 1002, in _get_childCount > File "baseObject.pyc", line 62, in __get__ > File "baseObject.pyc", line 168, in _getPropertyViaCache > File "NVDAObjects\__init__.pyc", line 709, in _get_children > File "baseObject.pyc", line 62, in __get__ > File "baseObject.pyc", line 168, in _getPropertyViaCache > File "NVDAObjects\window\excel.pyc", line 898, in _get_firstChild > File "monkeyPatches\comtypesMonkeyPatches.pyc", line 87, in new__getattr__ > File "comtypes\client\lazybind.pyc", line 168, in __getattr__ > File "comtypes\automation.pyc", line 746, in _invoke > File "monkeyPatches\comtypesMonkeyPatches.pyc", line 32, in __call__ > _ctypes.COMError: (-2147418111, 'Call was rejected by callee.', (None, None, None, 0, None)) > >>> sheet.childCount > Traceback (most recent call last): > File "<console>", line 1, in <module> > File "baseObject.pyc", line 62, in __get__ > File "baseObject.pyc", line 168, in _getPropertyViaCache > File "NVDAObjects\__init__.pyc", line 1002, in _get_childCount > File "baseObject.pyc", line 62, in __get__ > File "baseObject.pyc", line 168, in _getPropertyViaCache > File "NVDAObjects\__init__.pyc", line 709, in _get_children > File "baseObject.pyc", line 62, in __get__ > File "baseObject.pyc", line 168, in _getPropertyViaCache > File "NVDAObjects\window\excel.pyc", line 898, in _get_firstChild > File "monkeyPatches\comtypesMonkeyPatches.pyc", line 87, in new__getattr__ > File "comtypes\client\lazybind.pyc", line 168, in __getattr__ > File "comtypes\automation.pyc", line 746, in _invoke > File "monkeyPatches\comtypesMonkeyPatches.pyc", line 32, in __call__ > _ctypes.COMError: (-2147418111, 'Call was rejected by callee.', (None, None, None, 0, None)) > >>> sheet.children > Traceback (most recent call last): > File "<console>", line 1, in <module> > File "baseObject.pyc", line 62, in __get__ > File "baseObject.pyc", line 168, in _getPropertyViaCache > File "NVDAObjects\__init__.pyc", line 709, in _get_children > File "baseObject.pyc", line 62, in __get__ > File "baseObject.pyc", line 168, in _getPropertyViaCache > File "NVDAObjects\window\excel.pyc", line 898, in _get_firstChild > File "monkeyPatches\comtypesMonkeyPatches.pyc", line 87, in new__getattr__ > File "comtypes\client\lazybind.pyc", line 168, in __getattr__ > File "comtypes\automation.pyc", line 746, in _invoke > File "monkeyPatches\comtypesMonkeyPatches.pyc", line 32, in __call__ > _ctypes.COMError: (-2147418111, 'Call was rejected by callee.', (None, None, None, 0, None)) > >>> sheet.getChild(0) There's also tdf#156657 about potentially limiting the amount of Calc cells to expose via a11y API, but that is currently waiting for feedback on what would be a proper way to do so. (I'm hesitant about the idea of just doing something without documentation on what's a proper way.) I've heard several times that in general, exposing only on-screen children is not great, since it e.g. breaks having a screen reader read out a whole document. (This is currently a problem with Writer, s. tdf#96492). Right now, I don't see a clear way forward on LO side and in my opinion, a11y clients like Windows Speech Recognition should also properly handle many children, so I think this should at least be reported to Microsoft. [1] and [2] are cases where something similar was addressed for NVDA and AT-SPI, but unfortunately, Windows Speech Recognition is closed source. [1] https://github.com/nvaccess/nvda/commit/0170323c19275febbaf6698f9d2aae68cafe571b [2] https://gitlab.gnome.org/GNOME/at-spi2-core/-/issues/138
I was the original reporter of this bug. When someone noticed a conflict with Windows Speech Recognition, I checked my own configuration. It was turned off. When I turned it on and then off again, the problem with Copy causing LibreOffice 7.4 to freeze disappeared. It has not reoccurred in a month since then. Thanks for posting about this conflict!
[Automated Action] NeedInfo-To-Unconfirmed
That is a strange automated change of the status of this issue. That aside, did anyone who worked on this reproduce my observation that the problem did not occur if Calc was launched from the command line? For me, it only happened when run from the windows shortcut. Maybe this is just something simple like the command line invoke didn't run the Speech feature at all, but I did want to mention it because e.g. if that feature were still launched but it got started up in a different way such that CMAccessible::get_accChildCount doesn't return 2147483648 but rather something meaningful, maybe that could lead somewhere. I will test it again but need to restart... LO won't launch at all
I was having problems with LO 7.6.2 Calc and Writer not starting at all (the splash screen came up but then went away, not launching) so I uninstalled. On reinstall of 7.5.0 and then 7.5.4.2, I can no longer reproduce the original problem even when the windows speech recognition is enabled. Strange. current OS: Edition Windows 11 Home Version 22H2 Installed on 2/22/2023 OS build 22621.2428 Experience Windows Feature Experience Pack 1000.22674.1000.0
(In reply to Barry L. Kramer from comment #64) > That is a strange automated change of the status of this issue. > > That aside, did anyone who worked on this reproduce my observation that the > problem did not occur if Calc was launched from the command line? For me, > it only happened when run from the windows shortcut. Maybe this is just > something simple like the command line invoke didn't run the Speech feature > at all, but I did want to mention it because e.g. if that feature were still > launched but it got started up in a different way such that > CMAccessible::get_accChildCount doesn't return 2147483648 but rather > something meaningful, maybe that could lead somewhere. > > I will test it again but need to restart... LO won't launch at all Your command line workaround worked well for me. Of course now that the program is working properly after toggling on and off the speech recognition, I'm no longer using the workaround.
I have to admit that I don't understand why this report is still set as unconfirmed. More than one user in this report has reported problems with copying a cell in Calc when Windows' Speech Recognition is ON. Additional points: * Speech Recognition might not be the only conflicting Windows' feature triggering a freeze in Calc when copying a cell (e.g. Windows 11's "Suggested Actions" might also be a cause, mentioned in other reports and in ask.lo.org, and/or Windows' Clipboard History). * The conflict might be reproduced with some LO versions but maybe not with others. * A possible workaround (according to at least one comment) could be to set Windows' Speech Recognition to OFF. Also possible: setting Windows' Speech Recognition back to ON might not trigger the problem; rebooting in-between might be part of the steps to try. YMMV. * Whether the problem is _consistently_ reproduced or not, it _is_ being reproduced, and users might keep blaming LO, so the conflict should rather be investigated and solved (instead of simply staying passive and claiming some possible "not-our-bug").
(In reply to ady from comment #67) > ... so the conflict should rather > be investigated and solved (instead of simply staying passive and claiming > some possible "not-our-bug"). Using this passive voice, do you mean that the conflict should do something itself; or do you actually assign someone? Meaning, that you likely have power to tell some volunteer developer to start working on this and that? Phrases like that are useless, and in fact rude. This bug wasn't set "NOTOURBUG", nor any other "we won't work on it" resolution. You have a point that it should be NEW - go ahead and change the status, since it is enough a single independent reproducing report, and a confirmation that it is indeed a problem (rather than expected behavior - which is obvious in this case), to mark it as such.
(In reply to Mike Kaganski from comment #68) > (In reply to ady from comment #67) > > ... so the conflict should rather > > be investigated and solved (instead of simply staying passive and claiming > > some possible "not-our-bug"). > > Using this passive voice, do you mean that the conflict should do something > itself; or do you actually assign someone? Meaning, that you likely have > power to tell some volunteer developer to start working on this and that? > > Phrases like that are useless, and in fact rude. This bug wasn't set > "NOTOURBUG", nor any other "we won't work on it" resolution. You have a > point that it should be NEW - go ahead and change the status, since it is > enough a single independent reproducing report, and a confirmation that it > is indeed a problem (rather than expected behavior - which is obvious in > this case), to mark it as such. @Mike, I didn't mean that. After several comments and even dupes, the report is still set as unconfirmed. That seems strange to me, and I don't understand why. In that context, it would look as a passive attitude, in the sense of the practical consequence. But perhaps there is a reason not to set it as new(?). Sometimes, when "a group" shares something (as oppose to one person in particular), then no one actually takes responsibility or action or cares enough to do something (e.g. wasting energy in a public place). Regarding my "not-our-bug" comment, it is just a possibility, that some would suggest such status (considering that it is not set to new, and I still don't know why). Since the report was/is not set to new, maybe someone would think that all these symptoms should rather be solved by MS. Maybe the problem is really not at all a bug in LO, but IMHO it would be better to try to find some way to make it work anyway, for the reasons I mentioned before in my prior comment. I don't see anything rude in that. On the contrary, it is a humble and respectful "ping" about this report (starting by sincerely asking for the possible reasons for this report not to be set as new, with an attempt to summarize the current situation), but maybe I am too naive.
(In reply to ady from comment #67) > I have to admit that I don't understand why this report is still set as > unconfirmed. Look at the history and you will see why: https://bugs.documentfoundation.org/show_activity.cgi?id=153131 The automatic script always sets from NEEDINFO to UNCONFIRMED after someone comments. It doesn't check what the status was before needinfo (in this case it was NEW).
Settings to "high - major" as it's a freeze from a common operation. Michael, Mike: do you think this is the same source cause as a memory increase when "offer suggested actions" is on? See bug 158691 and ady's comment 67.
(In reply to Stéphane Guillou (stragu) from comment #71) > Settings to "high - major" as it's a freeze from a common operation. > > Michael, Mike: do you think this is the same source cause as a memory > increase when "offer suggested actions" is on? See bug 158691 and ady's > comment 67. See comment 58, comment 60 and comment 61 for a first analysis and the potential cause of the freeze. (Speech recognition querying an insane amount of children/cells.) (In reply to ady from comment #69) > Regarding my "not-our-bug" comment, it is just a possibility, that some > would suggest such status (considering that it is not set to new, and I > still don't know why). Since the report was/is not set to new, maybe someone > would think that all these symptoms should rather be solved by MS. Maybe the > problem is really not at all a bug in LO, but IMHO it would be better to try > to find some way to make it work anyway, for the reasons I mentioned before > in my prior comment. As mentioned in comment 61, I still think it would be worth trying to report to Microsoft at least, and see whether they can/will do anything about it. [My hope was that somebody with particular interest in this bug would go ahead and do this, but if nobody else is interested in doing that, I can add that to my list of things to do at some point next year.] It may be they don't. And I don't say that the LO side shouldn't change, but as described in more detail in the above-mentioned comments, I currently don't see a straightforward way to avoid the problem without the risk of breaking other use cases. Of course, if anybody has any great idea, please don't hesitate to implement that (or at least mention it here), but at least my main focus so far was on more actionable things, while this one here was mostly one of the "wait for further input and potentially revisit later" kind. The discussion in https://gitlab.gnome.org/GNOME/gtk/-/issues/6204 might provide some helpful input (see in particular the comments from the Orca maintainer, Joanmarie Diggs), but that's also still ongoing.