In NVDA screen reader we are using content of IAccessible 2 attribute 'Formula' to let user know if the particular cell has formula inside. When this attribute is empty it is assumed that formula is not present. This worked well until in LO Calc 6.4 you've started exposing "!!br0ken!!' when there is no formula. For users every cell is now announced as having formula which is confusing and makes navigation inefficient. In short this is not appropriate usage of IA2 attribs. Please revert this! For the time being I've worked around the problem in NVDA.
That "!!br0ken!!" string usually means some out of bounds portion of a string was tried being accessed, it's not the real attribute's value. As this happens on Windows maybe Mike (on Cc) can reproduce (in a debug build an assert() in OUString should abort) and fix.
I'd need a sample code (even a pseudocode showing how to obtain a IAccessible2 interface reference - for what? spreadsheet?, and a sample data) to try to repro.
(In reply to Mike Kaganski from comment #2) > I'd need a sample code (even a pseudocode showing how to obtain a > IAccessible2 interface reference - for The easiest way would be to: 1. Download NVDA screen reader from https://www.nvaccess.org/download/ 2. Start the downloaded file, open empty sheet in Calc and when focus is on an empty cell press Insert+f1. 3. In the displayed log look for the line which starts with IAccessible2 attributes > what? spreadsheet?, just a cell > and a sample No sample needed. This happens even with empty cells. > data) to try to repro.
"Regression" after https://git.libreoffice.org/core/+/ab285c743afa1c8769581871d7b56374fd8c49f1 > author Noel Grandin <noel.grandin@collabora.co.uk> Sat Nov 02 18:59:49 2019 +0200 > committer Noel Grandin <noel.grandin@collabora.co.uk> Sun Nov 03 17:11:14 2019 +0100 > > loplugin:stringadd > > tweak the plugin to be more permissive, then validate by hand > afterwards which replaced strFor.replaceAt(0,1,"") with strFor.copy(1). Both methods are illegal on empty string, but the former asserted, then silently corrected wrong count; while the latter returns "br0ken". So the change actually revealed a pre-existing bug. We should likely make the former also result in "br0ken" on invalid input, to allow invalid use cases. This hopefully will be fixed with https://gerrit.libreoffice.org/c/core/+/92301
Mike Kaganski committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/de1dadd591862e38242cc2de7a4a658a9a8b67ac tdf#132147: formula may be empty It will be available in 7.0.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.
Mike Kaganski committed a patch related to this issue. It has been pushed to "libreoffice-6-4": https://git.libreoffice.org/core/commit/9088a1bac800d1fec7eb0a4102a47c17235b429e tdf#132147: formula may be empty It will be available in 6.4.4. 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.