1020603 - nsIAccessibleTable::GetCellAt is broken for tables having display:block tbody

Status: RESOLVED FIXED

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

Description

[alexander :surkov (:asurkov)]

if you have something like

<table>
  <tbody style="display:block">
    <tr>
      <td>long blabla</td>
      <td>bla</td>
    </td>
    <tr>
      <td>bla</td>
      <td>bla</td>
    </td>
  </tbody>
</table>

it's rendered as a table but nsTableOuterFrame methods don't work (and as consequence accessible table interface doesn't work too)

The code snippet can be used for scrollable tables, see http://www.imaputz.com/cssStuff/bigFourVersion.html. This bug needs to be fixed for complete fix of bug 1020510.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> it's rendered as a table but nsTableOuterFrame methods don't work 

In what sense?

The layout for the markup you provide has two tables.  There's an outer table that has a single (anonymous) row which has a single (anonymous) cell.  This cell contains a single block (the one for the <tbody>), which contains an (anonymous) table which then contains two rows.

So there are two nsTableOuterFrames here.  Which one are you calling methods on, which methods, and what do you expect them to do?

Comment 2

[alexander :surkov (:asurkov)]

I believe I call it on upper table outer frame. So it sounds like problem should be fixed on a11y side. However from a11y perspective we have one table accessible only (for top HTML table) and I don't have good ideas how to detect this case. For example, how to distinguish it from
<table><tr><td><table><tr><td></td></tr><tr><td></td></tr></table></td></tr></table>

How many tables are created if tbody hadn't display:block style? Btw, why do GetCetllAt(0, 0) may return table itself (not anonymous cell)?

Comment 3

[Boris Zbarsky [:bzbarsky]]

> However from a11y perspective we have one table accessible only

Is the goal to have table accessibles for markup tables or for layout tables?

Because on this page the markup table structure and the layout table structure are totally different from each other.

> How many tables are created if tbody hadn't display:block style?

Just one.

> Btw, why do GetCetllAt(0, 0) may return table itself (not anonymous cell)?

You mean the content node?  Because there is no "anonymous cell content node".  There's an anonymous frame, but it points to the <table> node, for lack of anything better to to point at.

Comment 4

[alexander :surkov (:asurkov)]

(In reply to Boris Zbarsky [:bz] from comment #3)
> > However from a11y perspective we have one table accessible only
> 
> Is the goal to have table accessibles for markup tables or for layout tables?

it's a good question, I always voted to stay closer to layout in terms of a11y tree but it seems many a11y people (including some other browser vendors) disagree (example bug 1007975). 

> > Btw, why do GetCetllAt(0, 0) may return table itself (not anonymous cell)?
> 
> You mean the content node?  Because there is no "anonymous cell content
> node".  There's an anonymous frame, but it points to the <table> node, for
> lack of anything better to to point at.

I see. Is there particular reason to not create a content node for anonymous frame?

Comment 5

[Boris Zbarsky [:bzbarsky]]

Yes.  You have nowhere sane to put it.

Comment 6

[alexander :surkov (:asurkov)]

a11y is much based on content, having no content requires special tricks. Could that be a good reason to create content?

Comment 7

[Boris Zbarsky [:bzbarsky]]

No.  Again, there is nowhere sane to put it.  You can't make it an actual parent of the table's kids, because that will totally mess up the DOM, for example.

Again, a11y needs to decide whether it's trying to surface the markup or the layout here.  Or possibly both, separately...

Comment 8

[alexander :surkov (:asurkov)]

ok, thanks, Boris. Moving to a11y component then (changing summary)

Comment 9

[Eitan Isaacson [:eeejay]]

Attachment: Bug 1020603 - Check table children for alternative frame types when mapping element. r?Jamie!

If an HTML table's children (tr/thead/tfoot) are anything but row or row
group frames, our layout-based HTMLTableAccessible implementation won't work.

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/3b1bd79fd0af
Check table children for alternative frame types when mapping element. r=Jamie

Comment 11

[Cosmin Sabou [:CosminS]]

https://hg.mozilla.org/mozilla-central/rev/3b1bd79fd0af