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
Thanks for posting, setting to new.
JoanMarie: just to complete information, on which LO version are you? FYI, last stable one is 4.3.4
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.
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.
I'm still seeing this issue in 5.0.0.5.
** Please read this message in its entirety before responding ** To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year. There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present. If you have time, please do the following: Test to see if the bug is still present on a currently supported version of LibreOffice (5.2.7 or 5.3.3 https://www.libreoffice.org/download/ If the bug is present, please leave a comment that includes the version of LibreOffice and your operating system, and any changes you see in the bug behavior If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a short comment that includes your version of LibreOffice and Operating System Please DO NOT Update the version field Reply via email (please reply directly on the bug tracker) Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not appropriate in this case) If you want to do more to help you can test to see if your issue is a REGRESSION. To do so: 1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) http://downloadarchive.documentfoundation.org/libreoffice/old/ 2. Test your bug 3. Leave a comment with your results. 4a. If the bug was present with 3.3 - set version to "inherited from OOo"; 4b. If the bug was not present in 3.3 - add "regression" to keyword Feel free to come ask questions or to say hello in our QA chat: http://webchat.freenode.net/?channels=libreoffice-qa Thank you for helping us make LibreOffice even better for everyone! Warm Regards, QA Team MassPing-UntouchedBug-20170522
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.
This also affects alert dialog as described here : https://mail.gnome.org/archives/orca-list/2017-August/msg00006.html Best regards.
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.
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.
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.
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.
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.