Bug 70588 - Accessible labels in alerts claim to be ROLE_PASSWORD_TEXT instead of ROLE_LABEL
Summary: Accessible labels in alerts claim to be ROLE_PASSWORD_TEXT instead of ROLE_LABEL
Status: VERIFIED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
4.1.2.3 release
Hardware: Other Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:4.2.0 target:4.1.4
Keywords:
Depends on:
Blocks: a11y-Linux
  Show dependency treegraph
 
Reported: 2013-10-17 20:38 UTC by Joanmarie Diggs
Modified: 2014-06-19 09:57 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
pyatspi listener (480 bytes, text/x-python)
2013-10-17 20:38 UTC, Joanmarie Diggs
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Joanmarie Diggs 2013-10-17 20:38:50 UTC
Created attachment 87800 [details]
pyatspi listener

Steps to reproduce:

1. Launch the attached pyatspi listener in a terminal.

2. Create a new document in Writer with the following two lines:

   Helllo World.
   This is a test.

3. With the caret at the end of "test.", Press F7 to begin spell checking.

4. You will be asked if you want to start the check at the beginning. Press the "Yes" button.

5. Press the "Correct" button to change "Helllo" into "Hello."

6. Press the "OK" button when the spell check is completed.

7. Press Alt+F4 to quit (which will prompt you to save).

Expected results: When the pyatspi listener prints out the alert windows and their contents, there will be no objects of ROLE_PASSWORD_TEXT because there are no password text objects* present.

Actual results: Every accessible label claims to be of ROLE_PASSWORD_TEXT. Aside from that being confusing, it makes the text be exposed by Gtk+ to assistive technologies as asterisks. Thus Orca could not present the contents even if it knew the objects were really labels.

$ ./window-activated.py
[alert | LibreOffice 4.1.2.3]
   0. [push button | Yes]
   1. [push button | No]
   2. [icon | ]
   3. [password text | ]
[alert | LibreOffice 4.1.2.3]
   0. [push button | OK]
   1. [icon | ]
   2. [password text | ]
[alert | Save document]
   0. [filler | ]
   1. [filler | ]
   2. [push button | Close without saving]
   3. [push button | Cancel]
   4. [push button | Save]
   5. [panel | ]
   6. [icon | ]
   7. [password text | ]
   8. [password text | ]

(And in answer to the inevitable question: I'm building LibreOffice master as I write this. If the build succeeds, I'll update this bug to indicate if the issue is still present. But historically, issues like this remain present until reported. So I'm filing it now. :) )

*A password text object is one which is editable and whose text is displayed as bullets or asterisks.
Comment 1 Joanmarie Diggs 2013-10-17 21:18:10 UTC
The results from LibreOffice built from master are the same. This bug is still present:

./window-activated.py
[alert | LibreOfficeDev 4.2.0.0.alpha0]
   0. [push button | Yes]
   1. [push button | No]
   2. [icon | ]
   3. [password text | ]
[alert | LibreOfficeDev 4.2.0.0.alpha0]
   0. [push button | OK]
   1. [icon | ]
   2. [password text | ]
[alert | Save document?]
   0. [filler | ]
   1. [panel | ]
   2. [icon | ]
   3. [password text | ]
   4. [password text | ]
   5. [filler | ]
   6. [push button | Close without saving]
   7. [push button | Cancel]
   8. [push button | Save]
Comment 2 Attila Hammer 2013-10-18 04:21:19 UTC
Hi Joanie,

I looked now Libreoffice Calc the testcase, Calc producing this issue too. Reproducation steps equals your testcase.
My Ubuntu 12.04.3 system I tested only Libreoffice 4.1.1.2 version this issue.

Attila
Comment 3 Niklas Johansson 2013-10-18 09:40:12 UTC
Thank you for the bug report.

I'm adding this bug to the meta-bug Bug 36549 - ACCESSIBILITY: Tracking bug for issues affecting a11y ATK and GNOME Orca screen reader support.

I can reproduce with master on ubuntu with gnome shell and the listener script from Joanmarie.

When inspecting LibreOffice from Accerciser on the same machine and it reports the labels in the spelling dialog as labels and not as password. I did similar tests on Windows with JavaMonkey and on Mac with Accessibility Inspector, and in both cases they report the correct type of object.

Joanmarie do you have any idea why Acceciser reports one thing and the script you supplied another?
Comment 4 Niklas Johansson 2013-10-18 10:13:18 UTC
I had another look with Accessibility inspector on Mac and in the Save Document dialog I see that the labels have AXSubrole: AXSecureTextField. But I still don't see the issue in the spelling dialog. I used LibreOffice 4.1.2.3 on Mac OS X 10.8.5. 

Changing to UI since it concerns dialogs in more than one of LibreOffice applications.
Comment 5 Joanmarie Diggs 2013-10-25 02:24:14 UTC
(In reply to comment #3)
 
> When inspecting LibreOffice from Accerciser on the same machine and it
> reports the labels in the spelling dialog as labels and not as password.

Sanity check: The spelling dialog, which is not an alert?

> Joanmarie do you have any idea why Acceciser reports one thing and the
> script you supplied another?

The script I supplied specifically looks at alerts; not dialogs. If the spelling dialog is of ROLE_DIALOG my script would not output any data from it. So are you sure that the objects you are looking at in Accerciser are the same ones that are being output by my script?
Comment 6 Commit Notification 2013-11-04 14:47:28 UTC
Caolan McNamara committed a patch related to this issue.
It has been pushed to "master":

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

Resolves: fdo#70588 MultiLineEdits don't need WB_WORDBREAK set



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 7 Commit Notification 2013-11-05 10:34:07 UTC
Niklas Johansson committed a patch related to this issue.
It has been pushed to "master":

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

Resolves: fdo#70588 MultiLineEdits don't need WB_WORDBREAK set



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 8 Commit Notification 2013-11-05 16:17:19 UTC
Niklas Johansson committed a patch related to this issue.
It has been pushed to "libreoffice-4-1":

http://cgit.freedesktop.org/libreoffice/core/commit/?id=9826dec6f6021dba9859458acb0eb04520e5979a&h=libreoffice-4-1

Resolves: fdo#70588 MultiLineEdits don't need WB_WORDBREAK set


It will be available in LibreOffice 4.1.4.

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 9 Peter Vágner 2013-12-20 07:50:05 UTC
This is definitelly fixed in libreoffice 4.1.4. I was finally able to test it with orca 3.10.2 as the libreoffice 4.1.4 update is now available in arch linux. Thanks to everyone involved.

Greetings

Peter
Comment 10 Jacobo Aragunde Pérez 2014-06-19 09:56:12 UTC
This bug was fixed some time ago, I've verified that in master again. Thanks!