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.
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]
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
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?
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.
(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?
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.
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.
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.
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
This bug was fixed some time ago, I've verified that in master again. Thanks!