Created attachment 93074 [details] accessible-event listener Steps to reproduce: 1. Create a Writer document with spelling errors 2. Load the attached accessible-event listener in a terminal 3. Press F7 to start spell checking 4. Arrow around in the text widget displaying the error ("Not in Dictionary") 5. Insert and delete text in the widget displaying the error Expected results: 1. After step 3, the tree printed out would include an accessible object implementing AtkText which displays the error. 2. When steps 4 and 5 are performed, accessible events would appear in the terminal Actual results: Neither of the above happen. In particular: [snip] -> [label | Not in dictionary] -> [scroll pane | Not in dictionary] -> [panel | ] -> [scroll bar | Vertical scroll bar] -> [push button | Ignore Once] [snip] And there are no accessible text events for that widget. Note: The latter (no accessible text events) likely follows from the former (no accessible object). So were it me, I'd start debugging the first issue and see if the second magically goes away when it is fixed. :)
I'm broadening this bug and raising its importance and severity because this issue is apparently not limited to the spell check dialog's Not in Dictionary text widget. I see the same problem in Calc's Validity dialog: * Criteria page's Entries: Inaccessible * Input Help's page Input help: Inaccessible * Error Alert's page Error message: Inaccessible If you type text, remove text, and arrow around in the above widgets, there should be accessible events. There are not. It seems like multiline text widgets are generally broken. At least for the ATK implementation.
Caolán: I believe you have been doing GUI related changes.(?) If so, any ideas on this one?
I just tried to access the spellchecker on my Mac. The text widget is not showing up in the Accessibility Inspector, nor is VoiceOver presenting its contents. This seems to be a cross-platform accessibility bug.... (And, yes, it's present in LibreOffice master -- built just now in Fedora 20.)
I am definitely seeing this on Windows, too. The No Text Events portion of this bug affects other dialogs as well, for example when you insert a table into a Writer document. The Insert/Table... dialog's text fields don't update their contents when you change the number of rows or columns, or the name of the table that is to be created. NVDA can read the new text when requested, but I don't see updates happening on my braille display as I type.
And it affects both 4.2.0 with experimental IAccessible2 support as well as 4.3 master builds with IA2 support on as the only option.
possibly due to the VclMultiLineEdit/MultiLineEdit split where MultiLineEdit was split into two pieces and most moved into vcl and the other based on it. Possibly we need to move the last piece into vcl too and re-merge them.
(In reply to comment #6) > possibly due to the VclMultiLineEdit/MultiLineEdit split where MultiLineEdit > was split into two pieces and most moved into vcl and the other based on it. > Possibly we need to move the last piece into vcl too and re-merge them. The problem with exposing IAccessibleText seems to be more widespread than just dialog components. I am seeing problems in Writer documents on paragraphs, table cells and others, too. Bug 75162 is also an indication of a problem here.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=da13dd9a3513fa003b5a3537f6d1fb4e8ce23262 Related: fdo#74242 #i104470# we now have a seperate CARET_CHANGED event 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.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=3d024d29fa7344240f6cf407d023ef3537b0a5a9 Related: fdo#74242 send selection change before caret change 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.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=49cecd8b41cac29cc9642944eaae5b5f63a1bd46 Related: fdo#74242 hook up a selection and caret change for multiline edits 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.
Caolan McNamara committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dbeb8d405eba695cefbcf2660d556d70731eac79 Resolves: fdo#74242 now VclMultiLineEdit's a11y work 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.
So.. * Spell Check widget accessible events appear in the terminal * Criteria page's Entries: now works * Input Help's page Input help: now works * Error Alert's page Error message: now works or at least they appear to do so for me. Assuming its satisfactory, then as we progress through the remaining non-converted dialogs and convert MultiEdits to VclMultiEdits things should work better. What we have here is to make use of the new CARET_CHANGED changed stuff for normal edits, then an extension to the VclMultiEdit to support SELECTION_CHANGED and CARET_CHANGED, which made input help and error alert work, then a conversion over of the SpellCheck widget and Criteria Page entries to that widgets to make those work too. Anything that isn't multiline edit widget related, like paragraphs and table cells, is out of scope for me in this issue.
Caolán: Thank you, thank you, thank you. :) I can confirm the text-changed and caret-moved events are now present, at least for Linux. I'll wait for the pre-built nightly for verification on my (old, slow) Mac Mini. ;) The one remaining regression that I'm aware of related to these multiline text widgets is missing object:state-changed:focused events. (Which should be emitted by the multiline text widget itself and not the parent panel.) I've opened bug 75229 for that. If you happen to have a bit more spare time for this issue, I'd be most grateful. (In reply to comment #12) > Anything that isn't multiline edit widget related, like paragraphs and table > cells, is out of scope for me in this issue. Agreed. And I've not noticed any regressions there. For me (Linux), it's just these multiline dialog widgets. Thanks again!
Clarification on some of my earlier comments: Bug 75162 turned out to be related to missing/wrongly assigned roles on Windows, not missing IAccessibleText interfaces in multiline edits or paragraph accessibles. I definitely agree that this bug is fixed now. I can confirm the fix in the Feb 20 @47-TDF nightly build. The braille display now updates with new text and correct cursor position when typing/changing a word in the spell checker or other fields. Thanks Caolán!