In (some?) Windows (CI?), the Special Characters dialog has two entries for the Space character (0x20), the second taking the place of the Exclamation mark (0x21). See for example output for the `BasicTestSpecialCharactersDialog` test at https://ci.libreoffice.org/job/gerrit_windows/148609/consoleFull#551126502d893063f-7f3d-4b7e-b56f-4e0f225817cd: * child 0: (0A6B2798) role=TABLE name="Select special characters in this area." description="Special character selection" * child 0: (0A9E84D0) role=TABLE_CELL name=" " description="Character code 0x0020 (32)" * child 1: (0A9EA8E8) role=TABLE_CELL name=" " description="Character code 0x0020 (32)" * child 2: (0AEB7F10) role=TABLE_CELL name=""" description="Character code 0x0022 (34)" * child 3: (0AEB79E8) role=TABLE_CELL name="#" description="Character code 0x0023 (35)" I am not sure if it's specific to something in the CI environment or what though. I don't have a Windows at hand to test, but a friend tested 7.4.3.2 on a regular Windows 11 and didn't see the issue there. It can maybe depend on LO version, Windows version, running the environment, etc?
Created attachment 185723 [details] Screenshot of a11y tree on Windows in Inspect tool
This looks like a bug in the Windows a11y bridge (winaccessibility). The character is shown just fine in the dialog, but the a11y object/description appears to be wrong: NVDA announces the wrong character code and this can also be seen in the Inspect tool's a11y tree, s. screenshot attachment 185723 [details]. It's just fine in Accerciser on Linux, though. Version: 7.4.5.1 (x64) / LibreOffice Community Build ID: 9c0871452b3918c1019dde9bfac75448afc4b57f CPU threads: 4; OS: Windows 10.0 Build 19045; UI render: Skia/Raster; VCL: win Locale: en-US (en_US); UI: en-US Calc: threaded
(In reply to Michael Weghorn from comment #2) > This looks like a bug in the Windows a11y bridge (winaccessibility). > > The character is shown just fine in the dialog, but the a11y > object/description appears to be wrong: NVDA announces the wrong character > code and this can also be seen in the Inspect tool's a11y tree, s. > screenshot attachment 185723 [details]. > > It's just fine in Accerciser on Linux, though. But then the a11y test uses the LO-internal a11y API, so the wina11y bridge shouldn't be relevant at least for the CI issue where this was originally observed...
Thanks for looking into this! (In reply to Michael Weghorn from comment #3) > But then the a11y test uses the LO-internal a11y API, so the wina11y bridge > shouldn't be relevant at least for the CI issue where this was originally > observed... Yeah, that should not be it. Maybe a bad special case internally? There are non-bridge special cases, like e.g. adding the keyboard shortcuts to menu item names on Windows, so maybe there's more?
OK I can confirm a11y is wrong indeed on 7.4.3.2 as well, while the display is correct. PS: great finding for the crasher, it indeed is barely testable as is.
Suggested change that also adds the initial test case back: https://gerrit.libreoffice.org/c/core/+/148423
Michael Weghorn committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/65f672b27f84682764f924a3da3cecbafc88b278 tdf#153918 svx a11y: Drop old items when switching FontCharMap It will be available in 7.6.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.