Bug 1472024 is still not fixed - Assertion failure: false (MOZ_ASSERT_UNREACHABLE: Bogus row index?), at src/layout/tables/nsCellMap.cpp:361
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
People
(Reporter: emilio, Assigned: Jamie)
References
(Blocks 1 open bug)
Details
(Keywords: assertion, testcase)
Attachments
(2 files)
+++ This bug was initially created as a clone of Bug #1472024 +++
The crashtest added there asserts after bug 1839455. It seems the bug is still not fixed because I can repro locally even without that patch with GNOME_ACCESSIBILITY=1.
For the analysis, see the attached frame tree. The lines tagged with XXX are two tables and one cell.
The cell is the cell we're querying the indices at, which is in the second table. But it's Table() accessible returns the table corresponding to the first frame.
It seems the accessibility tree is busted and doesn't have a node for the tbody's table (which is anonymous).
|
||
Updated•1 year ago
|
|
|
||
Updated•1 year ago
|
|
||
Comment 1•1 year ago
|
||
Unable to reproduce bug 1843389 using build mozilla-central 20230713214846-a097691d609b. Without a baseline, bugmon is unable to analyze this bug.
Removing bugmon keyword as no further action possible. Please review the bug and re-add the keyword for further analysis.
|
Assignee | |
Comment 2•1 year ago
|
||
The way in which this reproduces possibly changed after bug 1832261. Either that or this bug really never was fixed.
Anyway, we don't create an Accessible for that table because it isn't semantically a table. I think the correct fix here is to tweak HTMLTableAccessible so that it always uses the correct table frame when trying to get row/col span info. There are a few other bits of cleanup we can do while we're at it. I think we should be able to get the nsTableCellFrame, then call GetTableFrame, then call GetEffectiveCol/RowSpan passing the nsTableCellFrame.
Alternatively, we could still call Table() and verify that the table we get there is the table associated with the cell. That would stop us from using span info from the wrong table. I'm not sure it's worth it, though as we'd still have to get the table frame to verify that.
|
|
Assignee | |
Comment 3•1 year ago
|
||
In some edge cases (such as in accessible/tests/crashtests/1472024-1.html), there can be an outer HTML table which contains an inner table according to layout, but the inner table isn't included in the a11y tree.
The inner table has no semantic value, so including it wouldn't be appropriate.
However, HTMLTableAccessible::Col/RowExtent previously retrieved the table using the a11y tree, which meant we used the layout frame for the outer table instead of the inner table.
This resulted in assertions.
To fix this, always ask the cell's layout frame for the correct table frame, rather than walking the a11y tree.
As a bonus, this simplifies and trims the code somewhat.
|
||
Updated•1 year ago
|
Pushed by jteh@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/5418f35a9d73 HTMLTableCellAccessible::Col/RowExtent: Get the table frame from layout instead of walking the a11y tree. r=nlapre
|
||
Comment 5•1 year ago
|
||
| bugherder | ||
|
||
Updated•11 months ago
|
Description
•