Open Bug 1636807 Opened 2 months ago Updated 2 months ago

display: block table cells get wrong coordinates when inside a normal <tr>


(Core :: Disability Access APIs, defect, P2)





(Reporter: Jamie, Unassigned)


(Blocks 1 open bug)


Here we go again.


  1. Open this URL:
    data:text/html,<table><tr><th>a</th><th style="display: block;">b</th><th style="display: block;">c</th><th>d</th></tr></table>
  2. Query the (0-based) column indices for b and c.
    • Expected: 1 and 2.
    • Actual: 0 and 0.
  3. Query the (0-based) column index for d.
    • Expected: 3.
    • Actual: 2.

I haven't debugged this, but here's what I think is happening:

  1. The tr element gets an HTMLTableRowAccessible, which is correct.
  2. As specified by MarkupMap, the th element gets an HTMLTableHeaderCellAccessible because it's a child of an HTML table row.
  3. Things fail because an HTMLTableHeaderCellAccessible needs an nsTableCellFrame, which this doesn't have because it's display: block.

I think we shouldn't use HTMLTableHeaderCellAccessibleWrap for display: block. I guess we can achieve that by checking for AccessibleType() eHTMLTableCellType.

Impact: This causes incorrect table coordinates to be reported by screen readers for affected tables, as well as making screen reader table navigation impossible.
S3 because while this is pretty nasty, I don't know of any cases of it occurring in the wild.
Originally reported as:

(In reply to James Teh [:Jamie] from comment #0)

I think we shouldn't use HTMLTableHeaderCellAccessibleWrap for display: block.

That would only fix step 2, cells b and c. The final th (cell d) would still have an incorrect column index (step 3) because that's what we get from layout. I guess layout treats a block element between two cells as a single cell, regardless of what element it is. The only way I see to fix that is to use our own ARIA table calculation code for everything, even HTML tables.

You need to log in before you can comment on or make changes to this bug.