Apache OpenOffice (AOO) Bugzilla – Issue 123629
[ia2] Calc: Invalid focus event fired after editing cell
Last modified: 2017-05-20 10:35:36 UTC
Str: 1. Create a new spreadsheet in Calc. 2. Ensure you are on the first cell (A1). 3. Type any letter (such as "t"), which will begin editing this cell. 4. Press escape to cancel editing. Result (correct): Focus is correctly fired on the A1 cell. 5. Type any letter (such as "t"), which will begin editing this cell. 6. Press left arrow to complete editing and accept the change. Expected: A focus event should be fired for the A1 cell. Actual: An invalid focus event is fired; i.e. calling IAccessible::accChild on the event's child ID fails. 7. Type any letter (such as "t"), which will begin editing this cell. 8. Press right arrow to complete editing, accept the change and move to B1. Expected: A focus event should be fired for the B1 cell only. Actual: An invalid focus event is fired (as in step 6), then a valid focus event is fired on the B1 cell. The result in step 6 causes broken focus for screen reader users. The result in step 8 doesn't break focus (since a valid focus event is fired last), but does cause extraneous output first.
Confirmed on Windows 7 sp1 64-bit with AOO410m1(Build:9750) - Rev. 1538508 Rev.1538508 using Accprobe utility to track --tableCell data entry followed by with enter or cursor key movement has extra focus event ia2 role textFrame / msaa acccRole client area as [focusable] -- and then toggles to the correct tableCell and accName
(In reply to V Stuart Foote from comment #1) > using Accprobe utility to track --tableCell data entry followed by with > enter or cursor key movement has extra focus event ia2 role textFrame / > msaa acccRole client area as [focusable] Btw, AccProbe is actually reporting incorrect information there. The event is fired on a child ID for which IAccessible::accChild fails, but AccProbe doesn't acknowledge the accChild failure. Therefore, it uses CHILDID_SELF, which is the root object, hence the reporting of root pane/client. I've seen this bug in AccProbe before. I don't think AccProbe is being actively developed, so I haven't bothered to report it at this stage. > -- and then toggles to the correct > tableCell and accName The even more concerning issue is when you are in the A1 cell and you exit editing by pressing left arrow. In that case, you get the invalid focus event, but no valid focus event.
Root cause: no valid focus event will be fired when attempting to change a selected cell in editing status to an "out of bounds" cell. The invalid cell address will be corrected by a valid cell address which is same with the previous one. In this case the valid focus event will no fired on the same cell. Solution: identify this kind of cases and fire a valid focus event on the current selected cell.
"steve_y" committed SVN revision 1555694 into trunk: Bug 123629 - [ia2] Calc: Invalid focus event fired after editing cell
Verified, it works.
Tested with AOO410m1(Build:9750) - Rev. 1571087. A valid focus event is now fired last when editing and attempting to move to an "out of bounds" cell. However, there is still an invalid focus event first, as follows: (In reply to James Teh from comment #0) > 7. Type any letter (such as "t"), which will begin editing this cell. > 8. Press right arrow to complete editing, accept the change and move to B1. > Expected: A focus event should be fired for the B1 cell only. > Actual: An invalid focus event is fired (as in step 6), then a valid focus > event is fired on the B1 cell.
This invalid focus event is same with other cases. The focus is moved from an editing area in one cell to another cell. When attempting to move the focus to an "out of bounds" cell, the focus should also be unset from the previous cell and set to the new cell, but in this case the previous cell and the new cell are the same one cell. (In reply to James Teh from comment #8) > Tested with AOO410m1(Build:9750) - Rev. 1571087. > > A valid focus event is now fired last when editing and attempting to move to > an "out of bounds" cell. However, there is still an invalid focus event > first, as follows: > (In reply to James Teh from comment #0) > > 7. Type any letter (such as "t"), which will begin editing this cell. > > 8. Press right arrow to complete editing, accept the change and move to B1. > > Expected: A focus event should be fired for the B1 cell only. > > Actual: An invalid focus event is fired (as in step 6), then a valid focus > > event is fired on the B1 cell.