When running the bug_435226.py regression test and the single
KP_Enter is pressed, the where-am-I outputs braille but no
speech. In the bug_435226.debug file at this point we have:

73 label=<>
73 name=<Hm! She is made of harder stuff! Cardinal Fang! Fetch the COMFY CHAIR!>
67 label=<>
67 name=<Document view>
whereAmI:
  label=
  name=Hm! She is made of harder stuff! Cardinal Fang! Fetch the COMFY CHAIR!    
  role=paragraph
  keybinding=['', '', '']
  parent label=
  parent name=Document view
  parent role=unknown
  basicOnly=True
Finding top-level object for source.name=
--> obj.name=Document view
--> obj.name=
--> obj.name=
--> obj.name=spanish - OpenOffice.org Writer
--> obj.name=
73 name=<Hm! She is made of harder stuff! Cardinal Fang! Fetch the COMFY CHAIR!>
73 label=<>

--

If the test is run manually (and also synchronously to remove
that potential difference), then at the same point we get:

73 label=<>
73 name=<Hm! She is made of harder stuff! Cardinal Fang! Fetch the COMFY CHAIR!>
67 label=<>
67 name=<Document view>
whereAmI:
  label=
  name=Hm! She is made of harder stuff! Cardinal Fang! Fetch the COMFY CHAIR!    
  role=paragraph
  keybinding=['', '', '']
  parent label=
  parent name=Document view
  parent role=unknown
  basicOnly=True
Finding top-level object for source.name=
--> obj.name=Document view
--> obj.name=
--> obj.name=
--> obj.name=spanish - OpenOffice.org Writer
--> obj.name=spanish - OpenOffice.org Writer
73 label=<>
_getTextContents: caretOffset=16, nSelections=1
_getTextSelection: selection start=0, end=16
_getTextSelection: selected text=<Hm! She is made >
first text utterances=['', 'paragraph', 'Hm! She is made ']
SPEECH OUTPUT: ''
SPEECH OUTPUT: 'paragraph'
SPEECH OUTPUT: 'Hm! She is made '
text utterances=['selected', '']
SPEECH OUTPUT: 'selected'
SPEECH OUTPUT: ''
73 name=<Hm! She is made of harder stuff! Cardinal Fang! Fetch the COMFY CHAIR!>
73 label=<>

--

I haven't worked out why there is a difference yet.

Rich and I took a look at this yesterday.  Seems that the problem is not the regression test.  If you try the following:

1. Launch Orca

2. Open the document of your choice either via Nautilus or via the 
   terminal.

3. Arrow around for good measure (not necessary; merely a sanity
   check that Orca is doing the right thang).

4. Press KP_Enter for a basic whereAmI.

Orca will say jack.

At this point, the hierarchy looks like this:

+- name='soffice' role='application'
  +- name='None' role='frame' <----- No name
    +- name='spanish - OpenOffice.org Writer' role='root pane'
      +- name='None' role='panel'
        +- name='None' role='scroll pane'
          +- name='Document view' role='unknown'
            +- name='None' role='paragraph'

If you then quit Orca (leaving the OOo Writer window open), relaunch it, and redo steps 3 and 4 above, everything works as expected and the hierarchy looks like this:

+- name='soffice' role='application'
  +- name='spanish - OpenOffice.org Writer' role='frame' <----- Named
    +- name='spanish - OpenOffice.org Writer' role='root pane'
      +- name='None' role='panel'
        +- name='None' role='scroll pane'
          +- name='Document view' role='unknown'
            +- name='None' role='paragraph'

In StarOffice.py's WhereAmI Class we have this:

   def _speakParagraph(self, obj, basicOnly):
        """OpenOffice Calc cells have the role "paragraph" when
        they are being edited.
        """

        top = self._script.getTopLevel(obj)
        if top and top.name.endswith(" Calc"):
            self._speakCalc(obj, basicOnly)
        elif top and top.name.endswith(" Writer"):
            self._speakText(obj, basicOnly)

top is the frame, it doesn't endwith anything, hence we don't speak anything.

So.... This seems like another instance of the isSpreadSheetCell() bug/problem/fix:  We can't count on the frame having a name so if we need to do this check, we need to potentially look at the root pane name as well (or instead?).

This initially also struck me as YAOOB bug:  Why aren't we getting the frame name?  But then I tried the above steps with Accericser (launched Accerciser first, then launched Writer for the same document, and took a look at the hierarchy).  Accerciser knows what the name of the frame is.  So.... Why don't we?

Will:  Is there anything we could be doing to cause us to not have the correct frame name?

If you watch the screen very closely when performing the above steps, there seems to be a second (less than a second really) where the frame name goes from the generic Writer stuff to nothing to the document name + the generic Writer stuff.  Any chance we're getting the name during the transition and storing it?

(In reply to comment #2)
> Will:  Is there anything we could be doing to cause us to not have the correct
> frame name?
> 
> If you watch the screen very closely when performing the above steps, there
> seems to be a second (less than a second really) where the frame name goes from
> the generic Writer stuff to nothing to the document name + the generic Writer
> stuff.  Any chance we're getting the name during the transition and storing it?

The two things that come to mind are:

1) pyatspi is caching it, which is something we desire for performance reasons

2) an object:property-change:accessible-name event might not be issued 
   when the name changes

I believe the reason you'd see it in Orca and not in Accerciser is that the cache might be more persistent in Orca if Orca hangs on to a window reference somehow between calls.

As an experiment to see if it is cache related, you might try adding this line in your ~/.orca/user-settings.py file:

orca.settings.cacheValues = False

It *should* tell pyatspi not to cache data.

> As an experiment to see if it is cache related, you might try adding this line
> in your ~/.orca/user-settings.py file:
> 
> orca.settings.cacheValues = False

Bingo!  If I add that line, the bug in question goes away; remove it and the bug comes back.  Thanks!!

<thinking out loud>  I wonder if we can (and should try to) detect this condition and dump the cache data for the frame rather than do the _speakParagraph() hack I suggested above.

(In reply to comment #4)
> > As an experiment to see if it is cache related, you might try adding this line
> > in your ~/.orca/user-settings.py file:
> > 
> > orca.settings.cacheValues = False
> 
> Bingo!  If I add that line, the bug in question goes away; remove it and the
> bug comes back.  Thanks!!

Cool.  We now know the source of the problem.  Thanks for investigating this.

> <thinking out loud>  I wonder if we can (and should try to) detect this
> condition and dump the cache data for the frame rather than do the
> _speakParagraph() hack I suggested above.

Do you see *any* events that might give us a clue that something has changed?  If so, we could try to dump the cache there.  To experiment with this, I think you can add an event to pyatspi.constants.CACHE_EVENTS (look at at-spi/pyatspi/constants.py to see the source).

Created attachment 108254 [details]
debug.out while performing the task

Seems that we've already got the right events.  I don't think we're correctly updating the cache as a result.  Here's what I think is taking place:

1. Window activated.  Frame has no name. (ln 1)
   Frame goes into the cached objects.

2. Root pane gets focus.  It has no name. (ln 61)
   Root pane goes into the cached objects.

3. object:property-change:accessible-name for the root pane. (ln 115)
   This event is one of types defined in at-spi/pyatspi/constants.py
   for cache dumping.  Root pane leaves the cache (and winds up going
   back in there with its new name).

4. object:property-change:accessible-name for the frame. (ln 165)
   Again, we dump the frame from the cache and put it back in with
   its new name.

If we ask for the hierarchy at this point, we get:

+- name='soffice' role='application'
  +- name='spanish - OpenOffice.org Writer' role='frame' <-- Yea!
    +- name='spanish - OpenOffice.org Writer' role='root pane'

BUT if we ask for the ancestry, we get:

+- name='soffice' role='application'
  +- name='None' role='frame' <-- Oops!
    +- name='spanish - OpenOffice.org Writer' role='root pane'

Turns out that one of the things that gets cached in pyatpsi's accessible.py property cache is the parent.  Thus at step 3, our newly-named root pane has amongst its properties a parent of ROLE_FRAME which has no name.  At step 4, we update the cache for the object of ROLE_FRAME (hence we get the correct name when was ask for the hierarchy), but we don't re-update any children in the cache whose parent is that frame (hence the frame still has no name when we ask for the ancestry).

I dunno what the best or the most pythonic way to solve this problem is (and knowing me I didn't do either). ;-) That said, if you add this at the beginning of accessible._updateCache(), the problem goes away and the frame has a name, whereAmI works, etc.*

  for key, value in _ACCESSIBLE_CACHE.items():
    if value.__dict__.get('parent') == event.source:
        del _ACCESSIBLE_CACHE[key]

* As long as you're performing the task live.  When the regression tests are run the frame is still nameless. :-(

Created attachment 108255 [details]
regression test version

During the test:

1. Window activated.  Frame has no name. (ln 1)
   Frame goes into the cached objects (I assume)

2. Root pane gets focus.  It has no name. (ln 33)
   Root pane goes into the cached objects (I assume)

3. object:property-change:accessible-name for the root pane. (ln 60)
   This event is one of types defined in at-spi/pyatspi/constants.py
   for cache dumping.  Root pane leaves the cache (and winds up going
   back in there with its new name -- I assume).  BUT, the new name
   is still None. (????)

4. object:property-change:accessible-name for the frame. (ln 164)
   Again, we dump the frame from the cache and put it back in with
   its new name. (Which is also None)

But somehow, magically, by the time we have the caret-moved event at line 292, the root pane has its correct name.  Not sure when that happened or if something similar occurred with the frame (and if so why dumping the cache as described in the previous comment didn't make a difference).

I don't get it.... :-(

I think this may be a question for Eitan -- Mr. Pyatspi himself.  :-)  Eitan, any ideas?

Uh Oh.
Do we sense cracks in the fool-proof caching mechanism?
I'll look at this today/tomorrow.

Ok,

I was talking out of my back end yesterday.
Yeah, this is a pyatspi caching bug. Nothing to do with OpenOffice.

Essentially, if a cache is invalidated for a certain accessible, the invalidation is not persisted across all paper weights. So our cache updates were lacking, to say the least.

Ok, I gave the test above (bug_435226.py) a run, and with current trunk of pyatspi it works fine. Could I close this? Someone want to do the honors?

Confirmed.  You fixed it, feel free to do the honors. :-)  Thanks!!

Thanks Joanie for reporting back. This bug is fixed with pyatspi trunk.