Closed Bug 1499519 Opened 3 years ago Closed 3 years ago
Table cell coordinates sometimes not updated when rows are added/removed
This is intermittent, but it should be reproduceable within a few attempts. STR (with NVDA): 1. Open this test case: data:text/html,<table><tbody id="tbody"><tr><th>a</th></tr><tr id="rc"><td>c</td></tr></tbody></table><button onClick="rb = document.createElement('tr'); rb.innerHTML = `<td>b</td>`; tbody.insertBefore(rb, rc);">Add</button> 2. Press the Add button. 3. Press control+home to move to the start of the document. 4. Press down arrow to move to the "b" row. 5. Press down arrow again to move to the "c" row. Expected: NVDA should report "row 3 c" Actual: NVDA just reports "c" (no row number) Disabling the handler fixes this. This occurs because the row number reported for the "c" cell is row 2 (as it was before the button was pressed) instead of row 3. I think the problem here is that tables don't fire text inserted/removed events, since they don't have IAccessibleText. They do fire reorder events. However, AccessibleHandler doesn't invalidate the cache for reorder events. If I'm right, this should be a one line fix: add EVENT_OBJECT_REORDER to the switch statement in IsHandlerInvalidationNeeded in AccessibleWrap.cpp.
Note that this was tested with NVDA alpha builds with the new vbuf speed-ups. It's possible this will behave differently with NVDA stable, since it will re-render the entire table in this case.
Doesn't seem like it. I've added that event to the switch statement, made sure that build was using the handler, and can still reproduce the problem, literally on first try. Even when exploring the hierarchy with NVDA's object model, both rows 2 and 3 are announced as row 2. The table accessible however recognizes that it now has 3 rows.
Also additionally mapping EVENT_OBJECT_REORDER to nsIAccessibleEvent::TABLE_ROW_REORDER doesn't fix it.
This seems to be fixed by bug 1052866. (Marco also verified this in bug 1502260 comment 5.) I confess that I still don't fully understand how/why, but bug 1052866 is certainly more "correct" from a client perspective. I don't think it's worth putting additional time into figuring out exactly why this fix works.
Status: NEW → RESOLVED
Closed: 3 years ago
Depends on: 1052866
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.