Bug Hunting Session
Bug 86661 - Incorrect usage of ATK_ROLE_TEXT
Summary: Incorrect usage of ATK_ROLE_TEXT
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: Other All
: medium normal
Assignee: Samuel Thibault
URL:
Whiteboard: target:6.1.0 target:6.0.2
Keywords: accessibility
Depends on:
Blocks: a11y-Linux
  Show dependency treegraph
 
Reported: 2014-11-24 12:51 UTC by Joanmarie Diggs
Modified: 2018-03-21 15:59 UTC (History)
10 users (show)

See Also:
Crash report or crash signature:


Attachments
proposed fix (672 bytes, patch)
2018-02-20 16:19 UTC, Samuel Thibault
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joanmarie Diggs 2014-11-24 12:51:39 UTC
Steps to reproduce:
1. Launch Writer and type some text.
2. Use find and replace to do a "replace all"
3. Use Accerciser to examine the resulting results dialog (where it says Search key replaced x times.")

Expected results: There would not be any object with ROLE_TEXT.

Actual results: The accessible object containing the string "Search key replaced 8 times" has ROLE_TEXT.

Impact: Orca does not present the results string because ROLE_TEXT is typically used for GtkTextView (e.g. the entire text widget in Gedit, which is GNOME's Notepad equivalent). For static text in dialogs, ROLE_LABEL is traditionally used.

There has admittedly been some confusion about what ROLE_TEXT is applicable to. We have done a couple of things in this regard: 1) Clarified this in the ATK documentation and 2) Created a new role (ATK_ROLE_STATIC). [1]

It would be very helpful if you could either use the new ATK_ROLE_STATIC (introduced in ATK v2.15.2) or the very old ATK_ROLE_LABEL to be consistent with our platform's usage of ROLE_TEXT.

On a related note, apparently IA2 has a text frame role which is appropriate for things like static text in a dialog. The IA2 text frame role in most -- if not all -- cases is NOT the same as ATK_ROLE_TEXT. Thus if the reason ROLE_TEXT was used was because of this presumed equivalency, then it would probably be worth doing a thorough search and correction for ATK.

[1] https://developer.gnome.org/atk/2.15/AtkObject.html#AtkRole
Comment 1 V Stuart Foote 2014-11-24 13:54:39 UTC
Thanks for posting, setting to new.
Comment 2 Julien Nabet 2014-11-24 19:23:51 UTC
JoanMarie: just to complete information, on which LO version are you? FYI, last stable one is 4.3.4
Comment 3 Niklas Johansson 2014-11-25 09:42:28 UTC
Right, I noticed this when trying to fix the issue with the text in message boxes being exposed as password text. As I remember it LibreOffice uses VclMultiLineEdit for the text. At first the intention was to change the role to ROLE_LABEL for labels and text like the ones described below, but I didn't find a good way to change it without the side effect that objects that should be exposed as ROLE_TEXT also would be changed to ROLE_LABEL. Since it at least was possible to get the text read I left it alone.

Maybe what we really want is to create a new class VclMultiLineLabel that inherits VclMultiLineEdit?

Note, I'm out on deep water here so my observations may very well be wrong.

Since I haven't been in contact with ATK_ROLE_STATIC before I won't comment on the differentiation between ATK_ROLE_STATIC and ROLE_LABEL at the moment.
Comment 4 Caolán McNamara 2015-01-19 16:34:35 UTC
Assuming this is a MessageDialog, there would be no problem at all to just call "SetAccessibileRole on the m_pPrimaryMessage and m_pSecondaryMessage widgets in MessageDialog::Execute if that solves the problem. They are merely r/o MultiLineEdits in order to allow the user to select and copy the text out of them.

or if its an InfoBox/etc, convert it to a MessageDialog if they work better, and/or do both if necessary.
Comment 5 Joanmarie Diggs 2015-08-14 23:24:54 UTC
I'm still seeing this issue in 5.0.0.5.
Comment 6 QA Administrators 2017-05-22 13:21:52 UTC Comment hidden (obsolete)
Comment 7 Alex ARNAUD 2017-05-30 17:01:41 UTC
Dear all,

I'm using LibreOfficeDev 5.5 from 2017-05-30.

I don't know how exactly to find the role of an element but in Accerciser I see label, not text. So it looks like the bug is no longer present.

Best regards.
Comment 8 Alex ARNAUD 2017-08-04 11:11:56 UTC
This also affects alert dialog as described here : https://mail.gnome.org/archives/orca-list/2017-August/msg00006.html

Best regards.
Comment 9 Samuel Thibault 2018-02-19 16:32:59 UTC
In the current libreoffice source code, that widget is now a GtkLabel, so the original bug report should be fixed. Concerning the Quit dialog, it is not fixed yet, I'll have a look at adding SetAccessibleRole.
Comment 10 Samuel Thibault 2018-02-20 16:19:24 UTC
Created attachment 140018 [details]
proposed fix

Well, using SetAccessibleRole can't work, since Edit redefines getAccessibleRole. The attached patch, which sets the proper role directly in getAccessibleRole, however works fine. I'll submit it through gerrit.
Comment 11 Commit Notification 2018-02-21 10:35:46 UTC
Samuel Thibault committed a patch related to this issue.
It has been pushed to "master":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=fa775ed30ad8969dacca34ddb63b76a89d8ba7da

tdf#86661 a11y: give ROLE_LABEL to read-only edit

It will be available in 6.1.0.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 12 Commit Notification 2018-02-21 13:57:34 UTC
Samuel Thibault committed a patch related to this issue.
It has been pushed to "libreoffice-6-0":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=b1c0169fa7079d1701625ce4f05d871093b482fc&h=libreoffice-6-0

tdf#86661 a11y: give ROLE_LABEL to read-only edit

It will be available in 6.0.2.

The patch should be included in the daily builds available at
http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
http://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 13 Alex ARNAUD 2018-02-23 15:55:06 UTC
Hello all,

I confirm that the bug is fixed on Debian Sid with LibreOfficeDev 6.1 GTK3 built the 2018-02-23.

Thanks a lot Samuel for your really great job.

Best regards.