Created attachment 87020 [details]
aforementioned test case

Created attachment 87727 [details]
Orca debug whilst trying to reproduce the problem.

Problem reproduced.

Here's my debug.out from testing this.

(OOo Calc already started and spreadsheet loaded and
frozen and focus was on one of the cells in row 1.)

Highlights:

* Line 530 - setting row one as the dynamic column headers.
* Line 782 - moving Left (after previously moving down to row 2).
* Line 809 - just the cell contents spoken.
* Line 882 - Alt-w to bring up the Window menu.
* Line 1203 - Down to the Freeze menu item.
* Line 1286 - Return to toggle state of Freeze menu item.
* Line 1448 - Right in spread sheet.
* Line 1475 - Still just the cell contents spoken.
* Line 1783 - setting row one as dynamic column headers, after
              previously moving Up there.
* Line 1924 - moving Left  (after previously moving down to row 2).
* Line 1951 - speaking both the column header and the contents of 
              the spread sheet cell.

Now I just have to look at the bits in between and see if I can work
out why it's failing when you have a Frozen row.

Will and I were able to work out what was going on here by
using at-poke. When there is a frozen cell, then the component
hierarchy shows that there are two views: "Document view1"
and "Document view3", each of which contain a table. The frozen
cell is in one table; the rest of the spread sheet is in the
other.

For now we should just say that we don't support this feature
and move on to higher priority Orca items.

I'll leave the bug open, because we should still be able to
fix this. It'll just mean that we need to save more (or different)
state.

Created attachment 87952 [details]
Simpler test spread sheet. Cell B2 is initially frozen.

I've been looking into how difficult it would be to implement
something like we discussed in the team meeting on Tuesday.

The way that dynamic row/column headers currently work in the
StarOffice.py script (and don't forget that this is for Calc
and Writer), is to use a pair of dictionaries:

        self.dynamicColumnHeaders = {}
        self.dynamicRowHeaders = {}

When the user sets a dynamic row or column, then we do

        self.dynamicColumnHeaders[table] = row

or

        self.dynamicRowHeaders[table] = column

Double clicking clears those dictionary entries.

When we navigate a table, we do two checks for dynamic
row and/or column headers, both in _getBrailleRegionsForTableCellRow()
and _getSpeechForTableCellRow():

       if self._script.dynamicColumnHeaders.has_key(table):
           row = self._script.dynamicColumnHeaders[table]
           ...

and

       if self._script.dynamicRowHeaders.has_key(table):
           column = self._script.dynamicRowHeaders[table]
           ...

As we have seen, when you have a frozen cell, the table for the
dynamic row/column headers can potentially be different than the
table for the actual table contents, so there are no dictionary
entries.

So how should we handle this assuming we want to be able to actively
keep multiple dynamic row/columns for different tables at the same
time? In other words, I'm not sure that saving a pointer to the table
containing the dynamic table headers or columns is going to help here,
because how to you relate it to the table containing the current cell?
Note that in Writer you can have multiple tables within the same
document, so saving a handle to a higher object in the component
ancestry probably isn't going to help either.

Suggestions on how to fix this are most welcome...

> So how should we handle this assuming we want to be able to actively
> keep multiple dynamic row/columns for different tables at the same
> time?

Ah...this is a use case I wasn't aware of.  Multiple simultaneous tables, each with its down dynamic row/column header state complicates things.  

Can we make a simplifying assumption that we would not run into this situation when looking at a single sheet in oocalc?  That is, a single sheet in oocalc really represents a single table, and that splitting/freezing really just shows a different view of the same data?  If so, is there a way to detect we are on a single sheet?  If so, then maybe the code could still be made to work.

To follow up -- looks like "Frozen" cells gives Orca and the AT-SPI a brain freeze.  So...let's go for plan B, which is to:

1) Somehow detect that the frozen state is set (try not to do string compares if possible)

2) Pop up a dialog telling the user that dynamic row and column headers cannot be done when the frozen state is set and that the user should unfreeze things (making sure you leave docs for our translators :-))

The only concern with this is whether it is possible for a user to unfreeze things in a read-only spreadsheet.  If it's impossible to unfreeze things in such a case, then this might not be a good solution.

Let's shoot for doing this for GNOME 2.20.  GNOME 2.19.5 is the beginning of the string and UI announcement period, so it might be nice to get it done before then.  (Definitely need to get it done before 2.19.90, which is the UI freeze).

Okay, I'll need a bit more information before I can implement this
(assuming I can find a way to determine if we have frozen cells without
doing a string comparison on the the Freeze menu item).

What should the popup dialog look like? 
What wording do you want on it? What buttons?

I also feel it's weird that Orca is throwing up GUI for other 
applications. We don't do it (yet) with anything else. Won't the 
focus change to Orca while this is up? Is that likely to cause a
problem?

Does it need to be a dialog?  Couldn't it just be a quick spoken message?

(In reply to comment #10)
> Does it need to be a dialog?  Couldn't it just be a quick spoken message?
> 

Would this effect braille-only users?

Can't it speak and braille? The braille message perhaps
can tell the user what to do to get it to redisplay what
would normally go on the braille display if you don't think
we should implement transient braille messages.

> What should the popup dialog look like? 
> What wording do you want on it? What buttons?

I'm not sure. I'm guessing:

"ALERT: This spreadsheet has the frozen attribute set.  Dynamic row and column headers  will not work as expected.  Please make sure the Window->Freeze menu item is unchecked to remove the frozen attribute."

As for buttons, what does a standard alert look like?  

> I also feel it's weird that Orca is throwing up GUI for other 
> applications. We don't do it (yet) with anything else. Won't the 
> focus change to Orca while this is up? Is that likely to cause a
> problem?

We do it with the Find dialog.  

I'm not sure it will cause a problem.  Here's what I'd expect the user experience to be like:

0) OOo has focus
1) User presses Insert+r to set dynamic column headings
2) Orca pops up dialog, dialog gets focus
3) Orca presents dialog
4) User reads dialog, presses the dismiss button
5) Dialog goes away, OOo gets focus again
6) Orca presents current location in OOo

If this turns into a hairball (e.g., I suspect the worst might be detecting the frozen state in such as way so as not to be dependent upon a localized form of "Freeze"), we can go to plan C: just mark this as a known problem and document it in the Orca WIKI (http://live.gnome.org/Orca/OpenOffice#details).

> If this turns into a hairball (e.g., I suspect the worst might be detecting the
> frozen state in such as way so as not to be dependent upon a localized form of
> "Freeze"), we can go to plan C: just mark this as a known problem and document
> it in the Orca WIKI (http://live.gnome.org/Orca/OpenOffice#details).

In today's team meeting, we decided to lower this in priority and document it on the WIKI.

Rich also offered to write up the text and I offered to do the WIKI'ing.

Here's a first draft of that text. Feel free to munge it as you see fit.

IMPORTANT NOTE
--------------
The setting of dynamic rows and columns in Orca with OpenOffice.org
Spreadsheet with the ORCA_MODIFIER+r and ORCA_MODIFIER+c commands
will not work correctly if there is already row or column headings 
frozen in the spread sheet. This can be determined by seeing if the
Window->Freeze menu item is checked. To use Orca's dynamic rows and 
columns, this menu item must be unchecked.

Sounds good although it might be worth adding a bit on the purpose of freezing and why a user might see it.

Good point. Okay, here's a second draft. Test for the first
paragraph shameless stolen from:
http://www.learnopenoffice.org/CalcTutorial13.htm


IMPORTANT NOTE
--------------
One of the problems you will run into when using large spreadsheets 
is that as you scroll off the page you can no longer see your column 
or row headers. OpenOffice makes it easy to solve this problem with 
the window freeze function.

The setting of dynamic rows and columns in Orca with OpenOffice.org
Spreadsheet with the ORCA_MODIFIER+r and ORCA_MODIFIER+c commands
will not work correctly if there is already row or column headings 
frozen in the spread sheet. 

This can be determined by seeing if the Window->Freeze menu item is 
checked. To use Orca's dynamic rows and columns, this menu item must 
be unchecked.

And so it is done.  Thanks!  Feel free to fine tune things at http://live.gnome.org/Orca/OpenOffice.

Frozen cells are all kinds of broken. See this LibreOffice bug. LibreOffice needs to be the fixer. So closing as NOTGNOME.

This LibreOffice bug: https://bugs.freedesktop.org/show_bug.cgi?id=71435