Issue 123629

Summary: [ia2] Calc: Invalid focus event fired after editing cell
Product: General Reporter: James Teh <jamie>
Component: accessibilityAssignee: AOO issues mailing list <issues>
Status: CLOSED FIXED QA Contact:
Severity: Normal    
Priority: P3 CC: issues, steve.yin.aoo, vstuart.foote
Version: 4.1.0-dev   
Target Milestone: 4.1.0   
Hardware: PC   
OS: Windows, all   
Issue Type: DEFECT Latest Confirmation in: ---
Developer Difficulty: ---
Issue Depends on:    
Issue Blocks: 121767    

Description James Teh 2013-11-04 23:04:41 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.
Comment 1 V Stuart Foote 2013-11-07 04:31:10 UTC
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
Comment 2 James Teh 2013-11-07 04:50:08 UTC
(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.
Comment 3 Steve Yin 2014-01-06 07:34:47 UTC
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.
Comment 4 SVN Robot 2014-01-06 07:58:11 UTC
"steve_y" committed SVN revision 1555694 into trunk:
Bug 123629 - [ia2] Calc: Invalid focus event fired after editing cell
Comment 5 SVN Robot 2014-01-06 07:58:12 UTC
"steve_y" committed SVN revision 1555694 into trunk:
Bug 123629 - [ia2] Calc: Invalid focus event fired after editing cell
Comment 6 SVN Robot 2014-01-06 08:00:47 UTC
"steve_y" committed SVN revision 1555694 into trunk:
Bug 123629 - [ia2] Calc: Invalid focus event fired after editing cell
Comment 7 Steve Yin 2014-01-07 06:17:28 UTC
Verified, it works.
Comment 8 James Teh 2014-03-03 13:51:23 UTC
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.
Comment 9 Steve Yin 2014-03-11 07:09:48 UTC
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.