Description: I have JAWS 2022 screenreader and Libreoffice 7.3.0 on my PC (under Windows 10 system). I can't use Libreoffice with JAWS, because Libreoffice crashes. What is the probleme? Steps to Reproduce: 1. Start JAWS 2. Start Libreoffice 3. Start Writer or Calc Actual Results: 1. Start JAWS 2. Start Libreoffice 3. Start Writer or Calc Expected Results: Libreoffice crashed. Reproducible: Always User Profile Reset: No Additional Info: Microsot Office 20XX
Hi all, I can reproduce that using JAWS 2020 and 2021 with LO 7.3.1.3 on Win 10 X64. Writer seems to work, but calc immediately crashes. It doesn't matter if started via opening a file from explorer, the LO launcher or directly. It crashes on the installed and the portable version as well. I uploaded a crash report at https://crashreport.libreoffice.org/stats/crash_details/882fdbc6-e459-4b21-9123-dbb826105869 If you got further questions or want me to try something, don't hesitate :) Best Martin
Is this still the case with LibreOffice 7.4? If so, does it actually crash at once when Calc is started, or does it hang for a while before crashing? A while ago, I analyzed an issue with JAWS and Calc where the problem was that JAWS was requesting accessible objects for all children of the Calc table, which are more than 4 billion, which is the reason why LibreOffice hangs and then crashes when it runs out of memory. From what I could see back then, LibreOffice was behaving correctly though and the solution would in my understanding be a better handling on the JAWS side. Have you possibly tried reporting that to the JAWS developers as well so they can take a look?
*** Bug 151069 has been marked as a duplicate of this bug. ***
Created attachment 182585 [details] Backtrace I can reproduce with LO master as of commit 349e3af0c5dd. Attached is a backtrace. However, I can't see anything obviously wrong on LO side (state of the objects/variables looks OK to me at first glance) and the same code path is run e.g. with NVDA just fine. The last call in the backtrace that happens from within LO is this one [1]: NotifyWinEvent( EVENT_OBJECT_FOCUS,hAcc, OBJID_CLIENT,dChildID ); Everything else is then in the handling of the event in the platform a11y layer, so the crash might be caused by the event handling in JAWS and thus be an issue with JAWS rather than LO. I have filled the support form for JAWS on the FreedomScientific website and added a link to this report. (I don't have a JAWS license, just used the download from the website that can be run for 40 minutes, not sure whether that will be a problem regarding the support request...) I currently don't see what else could be done on LO side. [1] https://git.libreoffice.org/core/+/349e3af0c5dd5ed495ed61aab526f63c16f0e215/winaccessibility/source/service/AccObjectWinManager.cxx#246
The JAWS version I used is JAWS 2022.2207.25 - July 2022.
(In reply to Michael Weghorn from comment #2) > A while ago, I analyzed an issue with JAWS and Calc where the problem was > that JAWS was requesting accessible objects for all children of the Calc > table, which are more than 4 billion, which is the reason why LibreOffice > hangs and then crashes when it runs out of memory. From what I could see > back then, LibreOffice was behaving correctly though and the solution would > in my understanding be a better handling on the JAWS side. Note that this is not the same problem, the crash described here actually happens right when starting Calc.
IIUC this is New then.
(In reply to Michael Weghorn from comment #4) > I have filled the support form for JAWS on the FreedomScientific website and > added a link to this report. JAWS/Vispero support replied very quickly and I now got the info that this is fixed in the JAWS 2023 cycle: > Wanted to let you know that we identified the issue you reported and it should be fixed in JAWS 2023 cycle. Please look for the release notes when new versions of 2023 release to the public. -> closing this issue as NOTOURBUG, since the fix is in JAWS and not LibreOffice