Created attachment 78588 [details] [review]
Patch to hopefully implement this feature.

And not break anything else. ;-)

I've NOT checked it into CVS HEAD yet. 
Joanie, could you give it a try out 
please?

Thanks.

Created attachment 78592 [details]
simple sample table

I've found a couple of oddities.  I could not always reproduce them in sample-table.odt, so I've attached apples-oranges.odt. 

Test 1:
1. Launch Orca
2. Open apples-oranges.odt
3. Down arrow to cell a1
4. Press Insert R (nothing spoken)
5. Press Insert C (nothing spoken)
6. Arrow around to see if headers got assigned anyway (they did not)

Test 2:
1. Launch Orca
2. Open apples-oranges.odt
3. Down arrow to cell a1
4. Right arrow to cell b1
5. Press Insert R (Orca reports col headers are set to row 1 as expected)
6. Left arrow to cell a1
7. Press Insert C (Orca reports row headers are set to col b rather than col a)

Thanks Joanie. I'll have a look at these. 

The first problem is caused because when you arrow down from the 
initial line, you don't actually end up with focus in the table.
You'll notice that you don't hear the "table with 3 rows and 3 columns"
either. The accessible component hierarchy at this point is:

+-name='soffice.bin' role='application' state='' relations=''
  +-name='apples-oranges - OpenOffice.org Writer' role='frame' state='ACTIVE ENABLED RESIZABLE SENSITIVE SHOWING VISIBLE' relations=''
    +-name='apples-oranges - OpenOffice.org Writer' role='root pane' state='ENABLED SENSITIVE SHOWING VISIBLE' relations=''
      +-name=None role='panel' state='ENABLED SENSITIVE SHOWING VISIBLE' relations=''
        +-name=None role='scroll pane' state='ENABLED SENSITIVE SHOWING VISIBLE' relations=''
          +-name='Document view' role='unknown' state='EDITABLE ENABLED MULTISELECTABLE OPAQUE SHOWING VISIBLE' relations=''
            +-name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_TO'

If you move left or right, the it picks up that you are in a table,
and <orca modifier>-r and <orca modifier>-c will work.

I'm not sure there is anything we can do here. Will, is it worth filing
YAOOoB?

Created attachment 78599 [details]
Orca debug output for the second problem.

I've recreated it. It definitely doesn't happen every time.
Investigating...

Regarding Comment #4, just in case it's relevant....

> You'll notice that you don't hear the "table with 3 rows and 3 columns"

Actually, I do hear that info....

You can see from line 412 of debug.out, that when I did the
<Orca modifier>-F7, Orca thinks the locus of focus is still
on the B1 cell.

This suggests that the handling of one of the three events:

object:state-changed:focused
object:text-caret-moved
focus:

when moving around in table cells, is still incorrect.

I'll continue to look at this tomorrow.

Will, I'm still looking for a pointer to the documentation 
for what detail1/detail2 means for each event type...

Re: comment #6:

Well I don't hear it... ;-)

(In reply to comment #7)
> Will, I'm still looking for a pointer to the documentation 
> for what detail1/detail2 means for each event type...

It all depends on the event, of course, and the documentation doesn't really seem to exist.  :-( I've often inferred it by looking at the detail1/detail2 values for various events.  The ultimate source, however, is the coder behind the accessibility implementation.

(In reply to comment #4)
> If you move left or right, the it picks up that you are in a table,
> and <orca modifier>-r and <orca modifier>-c will work.
> 
> I'm not sure there is anything we can do here. Will, is it worth filing
> YAOOoB?

It seems like there might be a bug in OOo for this.  Is the problem that a focus event is not issued when you first arrow into a table?

Created attachment 78606 [details]
debug.out related to the first problem

If you look at this debug.out, you'll see in line 1082 I down arrowed (from outside of the table into cell A1). In line 1123, there's the resulting object:state-changed:focused event with detail1 == 1. setDynamicColumnHeaders gets called, but doesn't do anything (line 1345).

Rich, in response to comment #8, please see line 1126. ;-) ;-)

Thanks. I'll get back to it tomorrow. Joanie, if you do want to
take it further tonight, I'd look in setDynamicColumnHeaders().
Maybe do a "util.printAncestry(orca_state.locusOfFocus)" near 
the beginning. My guess is the locus of focus is bogus.

If it is, then this all goes back to comment #7 above. I suspect
we are not processing those three events correctly. i.e. we need to
better understand what detail1 means for all three of them, and
then which of them we need to process.

Check this out:  In cases where the feature worked as expected, util.printAncestry reports that we're one cell *to the left* of our actual location.  On the non-first-cell entry where it didn't work correctly, printAncestry indicates that we're one cell *above* our actual location.  On the first cell, I can confirm what Rich found in the second part of comment #4 (i.e. not in a table).


Down-Arrowed into A1, didn't work at all.

+-name='soffice.bin' role='application' state='' relations=''
  +-name='apples-oranges - OpenOffice.org Writer' role='frame' state='ACTIVE ENABLED RESIZABLE SENSITIVE SHOWING VISIBLE' relations=''
    +-name='apples-oranges - OpenOffice.org Writer' role='root pane' state='ENABLED SENSITIVE SHOWING VISIBLE' relations=''
      +-name=None role='panel' state='ENABLED SENSITIVE SHOWING VISIBLE' relations=''
        +-name=None role='scroll pane' state='ENABLED SENSITIVE SHOWING VISIBLE' relations=''
          +-name='Document view' role='unknown' state='EDITABLE ENABLED MULTISELECTABLE OPAQUE SHOWING VISIBLE' relations=''
            +-name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_TO'


Arrowed around and into B1, did work.

+-name='soffice.bin' role='application' state='' relations=''
  +-name='apples-oranges - OpenOffice.org Writer' role='frame' state='ACTIVE ENABLED RESIZABLE SENSITIVE SHOWING VISIBLE' relations=''
    +-name='apples-oranges - OpenOffice.org Writer' role='root pane' state='ENABLED SENSITIVE SHOWING VISIBLE' relations=''
      +-name=None role='panel' state='ENABLED SENSITIVE SHOWING VISIBLE' relations=''
        +-name=None role='scroll pane' state='ENABLED SENSITIVE SHOWING VISIBLE' relations=''
          +-name='Document view' role='unknown' state='EDITABLE ENABLED MULTISELECTABLE OPAQUE SHOWING VISIBLE' relations=''
            +-name='Table1-1' role='table' state='EDITABLE ENABLED MULTISELECTABLE SHOWING VISIBLE' relations=''
              +-name='A1' role='table cell' state='EDITABLE ENABLED SELECTABLE SHOWING VISIBLE' relations=''
                +-name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_FROM FLOWS_TO'



Arrowed around and into B2, Orca set the column headers to row 1.

+-name='soffice.bin' role='application' state='' relations=''
  +-name='apples-oranges - OpenOffice.org Writer' role='frame' state='ACTIVE ENABLED RESIZABLE SENSITIVE SHOWING VISIBLE' relations=''
    +-name='apples-oranges - OpenOffice.org Writer' role='root pane' state='ENABLED SENSITIVE SHOWING VISIBLE' relations=''
      +-name=None role='panel' state='ENABLED SENSITIVE SHOWING VISIBLE' relations=''
        +-name=None role='scroll pane' state='ENABLED SENSITIVE SHOWING VISIBLE' relations=''
          +-name='Document view' role='unknown' state='EDITABLE ENABLED MULTISELECTABLE OPAQUE SHOWING VISIBLE' relations=''
            +-name='Table1-1' role='table' state='EDITABLE ENABLED MULTISELECTABLE SHOWING VISIBLE' relations=''
              +-name='B1' role='table cell' state='EDITABLE ENABLED SELECTABLE SHOWING VISIBLE' relations=''
                +-name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_FROM FLOWS_TO'



Arrowed around and into C3, did work.

+-name='soffice.bin' role='application' state='' relations=''
  +-name='apples-oranges - OpenOffice.org Writer' role='frame' state='ACTIVE ENABLED RESIZABLE SENSITIVE SHOWING VISIBLE' relations=''
    +-name='apples-oranges - OpenOffice.org Writer' role='root pane' state='ENABLED SENSITIVE SHOWING VISIBLE' relations=''
      +-name=None role='panel' state='ENABLED SENSITIVE SHOWING VISIBLE' relations=''
        +-name=None role='scroll pane' state='ENABLED SENSITIVE SHOWING VISIBLE' relations=''
          +-name='Document view' role='unknown' state='EDITABLE ENABLED MULTISELECTABLE OPAQUE SHOWING VISIBLE' relations=''
            +-name='Table1-1' role='table' state='EDITABLE ENABLED MULTISELECTABLE SHOWING VISIBLE' relations=''
              +-name='B3' role='table cell' state='EDITABLE ENABLED SELECTABLE SHOWING VISIBLE' relations=''
                +-name=None role='paragraph' state='EDITABLE ENABLED FOCUSABLE MULTI_LINE MULTISELECTABLE SHOWING VISIBLE' relations='FLOWS_FROM FLOWS_TO'

Scratch the previous stuff, it's a red herring.  The pattern seems to be that the dynamic row/column header will get set to the row/column *you just left*.  Playing a bit of "let's guess what detail1 is", try setting the check to 0 in line 1483:

        # If we are FOCUSED on a paragraph inside a table cell (in Writer),
        # then speak/braille that parent table cell (see bug #382415).
        #
        if event.type == "object:state-changed:focused" and \
           event.source.role == rolenames.ROLE_PARAGRAPH and \
           event.source.parent.role == rolenames.ROLE_TABLE_CELL and \
           event.detail1 == 0 and \
           event.source.state.count(atspi.Accessibility.STATE_FOCUSED):

So far so good!!!

Disclaimer:  It's late and I'm tired, please don't take my word for the above being the fix. :-)

Sorry to be spammy, but btw:  I did *a lot* of checking/arrowing to see what all events one gets when entering/leaving/moving within a table.  It is consistently:

OBJECT EVENT: object:text-caret-moved                  detail=(-1,0)
OBJECT EVENT: object:state-changed:focused             detail=(0,0)
OBJECT EVENT: object:state-changed:focused             detail=(1,0)
OBJECT EVENT: object:text-caret-moved                  detail=(0,0)
OBJECT EVENT: focus:                                   detail=(0,0)

It *seems* we can count on a object:state-changed:focused whose detail1 is 0 as reliably as we can count on it being 1.

Created attachment 78629 [details] [review]
New revision of the patch.

Nice work Joanie! Thanks. New patch includes that fix. It seems to really
work well. Patch also includes a check at one point if this is a keyboard
event before getting the event_string.

I've checked the code into Orca CVS HEAD. Will/Mike, could you try it out
and give feedback? Thanks.

Thanks. Closing.