# bad: [3a5db37fadb4477261591bcae629661d527a3069] source 8ed224599ae7985b577f0bf737b2b9b2e8dd47b7
# good: [2c1cccc19f9e70d2ecbc9ba7815abd674ab6d858] source 6eeac3539ea4cac32d126c5e24141f262eb5a4d9
git bisect start 'master' 'oldest'
# good: [911e076c8252169ce657c96c2329ec9aa6348550] source 0ea41fea75cd1ac1d81fa57c4411e75a6b4001f0
git bisect good 911e076c8252169ce657c96c2329ec9aa6348550
# good: [adc55df032bef2a07dbcfb98ecb4accb42768c5e] source 1055a94124a82b236230d6f97c1c9f0db07deba3
git bisect good adc55df032bef2a07dbcfb98ecb4accb42768c5e
# bad: [04e9132a2c7e2940bb4ecd82cb0d5f47810abb47] source c0ee80f9787bc5e86fb7a342b567c0649253e1e3
git bisect bad 04e9132a2c7e2940bb4ecd82cb0d5f47810abb47
# good: [f4ddfff441c0d9865b3f7ca6ae481a23ac740432] source d59760428669a3e6b90524b9bc52829ece539c80
git bisect good f4ddfff441c0d9865b3f7ca6ae481a23ac740432
# bad: [a945b8c2b6e37049c2c7993a7a513a6506cc6295] source d9370a1406c3d6cf7ebdac5ea2f5a0069aba0814
git bisect bad a945b8c2b6e37049c2c7993a7a513a6506cc6295
# bad: [6195c21adf5da4e204daca7d6a7d15beccf19bc0] source ea9219fd3578bdcd0f7fd23bbc5b5e844e98ae5d
git bisect bad 6195c21adf5da4e204daca7d6a7d15beccf19bc0
# good: [03d964d881f49db82d428a748113fb0cfa650d78] source ace53eb17c6e2a2e614bb2ff5d99fa5ccfe79358
git bisect good 03d964d881f49db82d428a748113fb0cfa650d78
# good: [24cce4fecb86739c8ec14318dbf48f556fdd0ae6] source 91af898b2a9193219bd28aa64296eaf0e145beb6
git bisect good 24cce4fecb86739c8ec14318dbf48f556fdd0ae6
# good: [c04facbfc7f2c8be76f47787505481a7bd28b43d] source e5834a3967b3b182d1b7b7a5b500aaea2ea423be
git bisect good c04facbfc7f2c8be76f47787505481a7bd28b43d
# bad: [882c5a1fa6d3b215e1e147c73c68bf6d9ce58723] source 42b8d1c00e83c3907da7d14d21ebc0d203233a78
git bisect bad 882c5a1fa6d3b215e1e147c73c68bf6d9ce58723
# bad: [6c4c90026c179fcd53987910da274e7a3453ddc0] source cd1a3eb429c58e79bf427d3cbc0f74b44020d4ca
git bisect bad 6c4c90026c179fcd53987910da274e7a3453ddc0
# bad: [1d38bdbfcc8727f3461c43a1548e178ad5c22518] source 7a8ed362eb163ac15a000ba1cfc74b58315800a1
git bisect bad 1d38bdbfcc8727f3461c43a1548e178ad5c22518
# good: [a5f82c16931d783258a001297524e8bce2d71b90] source 3e7bea5ece847dcd7234f7e7fd310b1daab0eec1
git bisect good a5f82c16931d783258a001297524e8bce2d71b90
# first bad commit: [1d38bdbfcc8727f3461c43a1548e178ad5c22518] source 7a8ed362eb163ac15a000ba1cfc74b58315800a1

I can indeed confirm the issue with libreoffice 6.1.0.3 running on Arch linux.

I cannot confirm the issue using Orca 3.28.0 and LibreOffice 6.0.3.2 on Ubuntu 18.04 LTS.

For me, Orca speaks the formatting correctly when creating a new writer document and pressing Orca + F.

The commit that introduced the regression was 7a8ed362eb163ac15a000ba1cfc74b58315800a1. Adding CC to Tomaž Vajngerl. Do you have any ideas on this one? It is a major regression for those of us that use screen readers.

*bump. This is a critical bug because it prevents screen reader users from getting formatting information in documents.

Setting this to new since another user confirmed it.

Orca is getting absolutely no attributes when it asks for the attribute run or the default attributes. And the following console errors appear:

** (soffice:14): WARNING **: Exception in get_run_attributes()
** (soffice:14): WARNING **: Exception in get_default_attributes()

Hello all,

@MMeeks: A bibisect seems to indicate that a Collabora developer has introduced a huge regression to accessibility on LibreOffice 6.1. The user impact is major because user of Orca (mostly blind people) could no longer access to formatting information of the text they write. Could you make it possible for you to help us to figure out this regression?

At Hypra we're working on a non-regression tool for such regression but it's in early stage right now. We hope in the future such regression couldn't happen.

Best regards,
Alex.

> @MMeeks: A bibisect seems to indicate that a Collabora developer has
> introduced a huge regression to accessibility on LibreOffice 6.1.

Regressions are an expected part of any development. Of course, if you do no development, you get no regressions =) I am optimistic that LibreOffice 6.0 will not have this particular problem - and we should fix 6.1 where we can.

> so this appears to be only a Linux regression.

The patch in question:
https://gerrit.libreoffice.org/gitweb?p=core.git;a=patch;h=7a8ed362eb163ac15a000ba1cfc74b58315800a1

has no Linux conditionality whatsoever.

As such - I suspect that this is actually an ORCA issue - of expecting an image to have a URL that can be read to people for all graphics, when this is no longer the case necessarily. The deprecated properties are 'ParaBackGraphicURL', 'BackGraphicURL', 'HeaderBackGraphicURL', 'FooterBackGraphicURL' 

I imagine the code path that is hit is:

+        case MID_GRAPHIC_URL:
+        {
+            throw uno::RuntimeException("Getting from this property is not unsupported");
+        }
+        break;

I would suggest grepping ORCA for where these properties are fetched and handling the exception.

HTH.

As Joanmarie mentioned, simply no attribute show up at all. Orca is not requesting for a particular kind of attribute, it just gets get_run_attributes called, i.e. vcl/unx/gtk/a11y/atktext.cxx:text_wrapper_get_run_attributes(), which does not take any particular attribute name, just the offset of the text whose attributes should be returned, but an exception gets raised there, and thus no attribute at all is returned. So it seems that it's soffice's text_wrapper_get_run_attributes itself which is now misbehaving with these properties removed (and similar for text_wrapper_get_default_attributes, which doesn't even take offsets, just the text whose attributes should be returned).

Thanks for the details:

> it just gets get_run_attributes called,
> i.e. vcl/unx/gtk/a11y/atktext.cxx:text_wrapper_get_run_attributes()

What would really help would be a stack trace showing the frames from which we get an exception here. I guess putting a break-point in text_wrapper_get_run_attributes - and when it gets hit - adding one in __cxa_throw - and getting a trace when it is triggered should make solving this rather trivial.

Failing that cutting out:

editeng/source/items/frmitems.cxx /MID_GRAPHIC_URL/ around line 3920 and just returning an empty-string, and/or 'false' - would be interesting to see if it fails. Then again, I'd be a little surprised to see that exception affect writer.

Thanks !

Created attachment 145928 [details]
full backtrace

Here is the full backtrace I am getting, which does seem related to the bisected commit. I tried to single-step within SwAccessibleParagraph::_getDefaultAttributesImpl, the while ( aPropIt != aPropertyEntries.end() ) goes fine until that particular element.

I forgot to mention that ./sw/source/core/access/accpara.cxx:1719 is

                pItem->QueryValue( aVal, aPropIt->nMemberId );

in the first while loop of SwAccessibleParagraph::_getDefaultAttributesImpl

Thanks - before I got to it it looks like Michael fixed this one:

commit 81974604d859da8365146ce126f3584d902224b8
Author: Michael Stahl <Michael.Stahl@cib.de>
Date:   Fri Oct 12 16:37:32 2018 +0200

    editeng: do not throw from QueryValue implementation
    
    None of the other QueryValue throw; in case of a problem they return
    false without initialising the Any.

Thanks for reporting ! =) I assume this was back-ported to 6-1 ?

I can confirm that it works fine with https://dev-builds.libreoffice.org/daily/master/Linux-rpm_deb-x86_64@86-TDF/2018-10-23_18.02.41/

I don't see any backport to the 6.1 branch, it would be very welcome.

https://gerrit.libreoffice.org/62331 editeng: do not throw from QueryValue implementation

Thanks for the report.

oh there's a bug about this; sorry i completely forgot to backport the fix to 6.1, thanks for doing that...

was pushed to libreoffice-6-1 as commit 18a388c696567e6ddbf8c997ee0a9a686e7d80ed