Re: [orca-list] Wrong table recognition on NVDA snapshot page

[Joanmarie Diggs <joanmarie diggs gmail com>]

Hi Hermann.

> go to:
> http://www.nvda-project.org/wiki/Snapshots

Done.

> and check the table of downloadable snapshots:

Done -- I think. I only see one table there -- visually, using Orca, and
looking at the HTML source of the page. So I'm assuming it's the right
table.

> Orca indicates that there are 4 rows and 3 columns,

Yup, sure does. Up to this point I'm good. But I hope you'll forgive
the/my confusion about....

>  which is obviously wrong:

Huh?

> It should announce 4 rows and 4 columns.

Why? In other words, what are you basing your column count on? Visually
I see three columns; not four. But as we all know, especially with
tables, you can't rely upon your vision to give you the full story. So
I've copied and pasted the HTML source of the section in question --
including the paragraph which precedes the table so that we can figure
out if I have the wrong page/content/table. If I do my apologies. :-)
And in case I do, let me first answer your other question so that you
can stop reading if we're talking apples and oranges.

> To Joanie: Perhaps the first issue of the thermonuclear patch? :-(

Well, the short answer is that it's extremely unlikely. :-)

What the thermonuclear patch does is quite simple: It ignores all
caret-moved events when 1) we're on a link or image in document content,
and 2) Orca is controlling the caret, and 3) Orca has determined it
really should be doing so in this particular case. In other words, if
you're moving around in content and move to a link or an image and
Firefox suddenly announces, "hey, I just moved the caret to this totally
different location!" we will ignore this announcement and carry on.
Advantage of this approach: We're on occasion getting rather
unpredictable bogus events which cause us to loop/get stuck because we
believe Firefox when it suggests we should update our position.
Disadvantage of this approach: Maybe sometimes Firefox is telling us the
truth and therefore we should try to do more analysis (i.e. be less
"thermonuclear" about what we choose to ignore when Orca is controlling
the caret).

Anyhoo, I digress. Point is the patch should have nothing to do with how
many rows and/or columns a table has -- and/or how many we report. But
that said, who knows what the unintended side effects of a patch might
be, so it's great that you're questioning that rather than just ruling
it out without verification. A good way to verify the impact of the
patch would be to try reversing the patch, doing a make install, and
restarting Orca to see if the problem persists without the patch. On the
machine I'm currently on (which does not have the patch), Orca announces
4 rows and 3 columns. So if I'm indeed in the correct table, it would
seem that the problem at hand is independent of the patch.

Now on to the table (and its preceding paragraph) itself.

--- begin html source ---

<p>This is the main development branch. This code is under constant
development. It is therefore less likely to be stable and may even be
completely broken from time to time. You have been warned.</p>
<table>
<tr><th>Snapshot version</th><th>Date (UTC)</th><th>Download</th></tr>
<tr><td>r2401</td><td>Tue Sep 30 17:45:24 2008</td><td><a 
href="/snapshots/trunk/nvda_snapshot_trunk-r2401_installer.exe">installer</a> (9760 KB)<br/><a 
href="/snapshots/trunk/nvda_snapshot_trunk-r2401_portable.exe">portable archive</a> (8732 KB)</td></tr>
<tr><td>r2400</td><td>Tue Sep 30 05:10:54 2008</td><td><a 
href="/snapshots/trunk/nvda_snapshot_trunk-r2400_installer.exe">installer</a> (9760 KB)<br/><a 
href="/snapshots/trunk/nvda_snapshot_trunk-r2400_portable.exe">portable archive</a> (8735 KB)</td></tr>
<tr><td>r2399</td><td>Mon Sep 29 17:45:28 2008</td><td><a 
href="/snapshots/trunk/nvda_snapshot_trunk-r2399_installer.exe">installer</a> (9750 KB)<br/><a 
href="/snapshots/trunk/nvda_snapshot_trunk-r2399_portable.exe">portable archive</a> (8725 KB)</td></tr>
</table>

--- end html source ---

If it's the wrong table, stop reading. :-)

Table rows are defined by <tr> to start the row and </tr> to end the
row. I see 4 pairs of <tr></tr>. That would account for the 4 rows,
which we seem to agree is correct.

Table cells can be defined by pairs of <th></th> or <td></td> tags. The
former specifies that a cell is a table header; the latter that it's an
ordinary table cell. Looking at the above source, I see that there are
three table headers (each defined by <th></th>).

1. Snapshot version
2. Date (UTC)
3. Download

Similarly I see that rows 2 through 4 have three cells each (<td></td>).

1. r2xxx (where xxx is the rest of the revision number)
2. A date beginning with the day and ending with '2008'
3. A link for the installer, followed by its size, then
   a line break, a link for the portable archive followed
   by its size

So, again, I feel like I'm missing something fundamental (been one of
those days, I'm afraid), and for that I apologize. But.... If each of
the four rows contains three columns -- none of which are spanning
multiple columns -- doesn't that mean we have a uniform table of four
rows and three columns, as Orca is reporting?

Regardless, I'll take Orca out of the picture for a moment and use
Accerciser to see what is being exposed to us (i.e. what we're basing
our count on). I find Accerciser to be an excellent tool when it comes
to initially debugging things along the line of "Why on earth is Orca
doing *that*???".

If I select the table and then look at the contents of the Interface
Viewer page, I see the following when I expand Table:

Caption:None
Summary:None

Table Information
  Rows        4
  Columns     3

So the reason Orca is reporting 4 rows and 3 columns for this table
would seem to be because Firefox, via at-spi, is telling us that this
table has 4 rows and 3 columns. (If what I saw in Accerciser didn't jive
with what Orca was saying, then I'd be fairly certain we had an Orca bug
on our hands.)

Alternatively, I could have selected the table and used the iPython
console:

I type: acc.queryTable().nRows
I get: 4
I type: acc.queryTable().nColumns
I get: 3

So....

> Can anybody confirm this? 

Seems that I can.

> What is wrong with this simple table?

I don't want to say "nothing", but.... It seems *to me* to indeed be a
simple table -- one that is being exposed correctly via at-spi and being
reported correctly by Orca. So.... I don't know what's wrong with this
simple table. But if you can give me more details, I will do my very
best to get to the bottom of it.  Thanks for the report and continuing
to test that patch!!

Take care.
--Joanie