https://bugs.documentfoundation.org/show_bug.cgi?id=157160

Michael Weghorn <m.wegh...@posteo.de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Assignee|libreoffice-b...@lists.free |m.wegh...@posteo.de
                   |desktop.org                 |
             Status|NEW                         |ASSIGNED
           See Also|                            |https://bugs.documentfounda
                   |                            |tion.org/show_bug.cgi?id=15
                   |                            |7092

--- Comment #4 from Michael Weghorn <m.wegh...@posteo.de> ---
(In reply to Julien Nabet from comment #3)
> Michael: thought you might be interested in this one since it seems related
> to accessibility + qt considering the stacktrace.

This sounds almost the same as tdf#157092, but is actually a different case
(the newly "upgraded" assert from the fix for that one now getting triggered).

https://gerrit.libreoffice.org/c/core/+/156782 fixes the crash/assert for
Qt-based VCL plugins, s. commit message for details.

> Now I'm afraid there's more than this since V Stuart had problems on Windows.

That actually seems to be a different thing.

(In reply to V Stuart Foote from comment #1)
> Confirmed, but just the Options dialog closes without result. 
> No hang and LO continues to run.
> 
> =-testing-=
> Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
> Build ID: d88779fc86385dde1215fd28b78a69eacc6b4f97
> CPU threads: 8; OS: Windows 10.0 Build 19045; UI render: Skia/Vulkan; VCL:
> win
> Locale: en-US (en_US); UI: en-US
> Calc: threaded

This version doesn't contain the fix for tdf#157092 yet. I can't reproduce with

Version: 24.2.0.0.alpha0+ (X86_64) / LibreOffice Community
Build ID: f6a6b1454c7c765c0fc2ef9dc3e6111509a88307
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

Can you please retest with a newer build?
Just to mention it: Waiting for the search to do something instead of pressing
Enter (which closes the dialog) in step 4 is essential. I did press Enter at
first when trying the feature with qt6, since the search takes a rather long
time there and I thought "nothing was happening", so was wondering whether the
search had to explicitly triggered there by pressing Enter.

In any case, if this is still an issue, I think it should be reported
separately.

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to