Return table headers from the table cell level.

Return table headers for the individual cell

Update AXTableCell by adding methods for collecting header objects
for the individual cell. Provides also new WebAXObject API.

BUG=450255

[k.czech, 2015-02-06 00:12:10]

k.czech@samsung.com changed reviewers:
+ dmazzoni@chromium.org

[k.czech, 2015-02-06 00:32:49]

On 2015/02/06 00:12:11, k.czech wrote:
Hi Dominic, do you think I could get try bot access and bug editing permission
?.

[k.czech, 2015-02-10 08:54:54]

On 2015/02/06 00:32:49, k.czech wrote:
> On 2015/02/06 00:12:11, k.czech wrote:
> Hi Dominic, do you think I could get try bot access and bug editing permission
> ?.

Hi Dominic any chance to look at this ?

[k.czech, 2015-02-10 08:54:54]

On 2015/02/06 00:32:49, k.czech wrote:
> On 2015/02/06 00:12:11, k.czech wrote:
> Hi Dominic, do you think I could get try bot access and bug editing permission
> ?.

Hi Dominic any chance to look at this ?

[dmazzoni, 2015-02-13 07:13:34]

The code looks good, but I'm wondering whether it makes sense to compute this in
Blink. With the information we already have from Blink, could this be
implemented just as easily on the Chromium side?

Anything we compute in Blink we have to compute for every cell, whether we need
it or not.

If we defer to the Chromium browser side, we can wait until, e.g. a screen
reader actually moves focus to a cell and only compute this stuff on demand.
Does that make sense?

For example, BrowserAccessibilityWin::get_columnHeaderCells already tries to
implement this. Maybe it has a bug - and if so we should fix it - but would it
be possible to compute there?

[k.czech, 2015-02-13 15:13:56]

On 2015/02/13 07:13:34, dmazzoni wrote:
> The code looks good, but I'm wondering whether it makes sense to compute this
in
> Blink. With the information we already have from Blink, could this be
> implemented just as easily on the Chromium side?
> 
> Anything we compute in Blink we have to compute for every cell, whether we
need
> it or not.
Basically in terms of the row headers we only compute left hand side cells for
one particular row. Column headers are calculated the same way, we only operate
on a column direction top-bottom. This way we will find all the headers
(row/column) if there are any for one exact cell.

> 
> If we defer to the Chromium browser side, we can wait until, e.g. a screen
> reader actually moves focus to a cell and only compute this stuff on demand.
> Does that make sense?
This sounds very reasonable
> 
> For example, BrowserAccessibilityWin::get_columnHeaderCells already tries to
> implement this. Maybe it has a bug - and if so we should fix it - but would it
> be possible to compute there?
I will check this. Does it only go for Win platform ?

[dmazzoni, 2015-02-13 16:03:33]

On 2015/02/13 15:13:56, k.czech wrote:
> On 2015/02/13 07:13:34, dmazzoni wrote:
> > The code looks good, but I'm wondering whether it makes sense to compute
this
> in
> > Blink. With the information we already have from Blink, could this be
> > implemented just as easily on the Chromium side?
> > 
> > Anything we compute in Blink we have to compute for every cell, whether we
> need
> > it or not.
> Basically in terms of the row headers we only compute left hand side cells for
> one particular row. Column headers are calculated the same way, we only
operate
> on a column direction top-bottom. This way we will find all the headers
> (row/column) if there are any for one exact cell.
> 
> > 
> > If we defer to the Chromium browser side, we can wait until, e.g. a screen
> > reader actually moves focus to a cell and only compute this stuff on demand.
> > Does that make sense?
> This sounds very reasonable
> > 
> > For example, BrowserAccessibilityWin::get_columnHeaderCells already tries to
> > implement this. Maybe it has a bug - and if so we should fix it - but would
it
> > be possible to compute there?
> I will check this. Does it only go for Win platform ?

That's currently implemented as a Win platform function. We can share code with
other platforms if they have similar requirements.

[k.czech, 2015-02-13 16:15:31]

On 2015/02/13 16:03:33, dmazzoni wrote:
> On 2015/02/13 15:13:56, k.czech wrote:
> > On 2015/02/13 07:13:34, dmazzoni wrote:
> > > The code looks good, but I'm wondering whether it makes sense to compute
> this
> > in
> > > Blink. With the information we already have from Blink, could this be
> > > implemented just as easily on the Chromium side?
> > > 
> > > Anything we compute in Blink we have to compute for every cell, whether we
> > need
> > > it or not.
> > Basically in terms of the row headers we only compute left hand side cells
for
> > one particular row. Column headers are calculated the same way, we only
> operate
> > on a column direction top-bottom. This way we will find all the headers
> > (row/column) if there are any for one exact cell.
> > 
> > > 
> > > If we defer to the Chromium browser side, we can wait until, e.g. a screen
> > > reader actually moves focus to a cell and only compute this stuff on
demand.
> > > Does that make sense?
> > This sounds very reasonable
> > > 
> > > For example, BrowserAccessibilityWin::get_columnHeaderCells already tries
to
> > > implement this. Maybe it has a bug - and if so we should fix it - but
would
> it
> > > be possible to compute there?
> > I will check this. Does it only go for Win platform ?
> 
> That's currently implemented as a Win platform function. We can share code
with
> other platforms if they have similar requirements.

I'm wondering whether you could request a try-bot access and bug-editing
permissions for me ?