Steps to reproduce:

1) Run the attached standalone application in an xterm
2) Run gtk-demo, making sure GTK_MODULES=:gail:atk-bridge: prior to running
3) Open the "Editable Cells" or "List Store" or "Tree Store" demos under "Tree View"
4) Make sure the table in the chosen demo has focus
5) Position the mouse pointer over a cell and press F11, watching the output in the xterm where you are running the standalone application

You will find that the accessible returned is actually the cell underneath the cell with the pointer.  This is even the case when the pointer is over a column header.  It's as though the column header doesn't exist.

Created attachment 56791 [details]
Test case

Apologies for spam... ensuring Sun a11y folks are cc'ed on all current accessibility bugs.

*** Bug 344000 has been marked as a duplicate of this bug. ***

Copying addition info from Bug #344000

"Also, the behavior of getAccessibleAtPoint is inconsistent once the table has
been scrolled and resized. Sometimes, the reported cell is incorrect in both
row and column after the scroll."

Hi Will, as I tried, the script doesn't output anything when I pressed F11. Is there any step I missed?

I just ran "python bug_325809.py"

On a Sun keyboard, the F11 key generates the "SunF36" not "F11".
Similar for F12. So the the notifyKeystroke() routine in the
script needs to be adjusted to something like:

def notifyKeystroke(event):
    if event.event_string == "F12" or event.event_string == "SunF37":
        shutdownAndExit()
    elif event.event_string == "F11" or event.event_string == "SunF36":
        ...

Hi Rich, I have tried the script and there is still a problem.

notifyKeystroke(event) never returns and prints nothing. It seems blocked when calling :component = focusedObj.queryInterface(\
                "IDL:Accessibility/Component:1.0")

Is there anything I have ever missed ? Thx

Created attachment 86562 [details]
New test case that does ref/unref

The old test case neglected to do a ref/unref on the accessible it was watching.  Try this new one - I just tested it and it works on Ubuntu Feisty.  I also added some SunF3? references as well.  Thanks!

Hi, Willie, the test case runs very well, thx!

By checking codes of gail and gtk, we consider this may be a gtk's bug.

In gailtreeview.c, function gail_tree_view_ref_accessible_at_point() computes the position (x,y) of whole treeview's widget, and passes x and y directly to gtk_tree_view_get_path_at_pos().

However, gtk_tree_view_get_path_at_pos() assume the position is based on priv->bin_window which does not include header_window. For we find gtk_tree_view_button_press() has the same code for finding the clicked node, which runs well.

By checking the GtkTreeView's API, we find it impossible to decide header's actual height. So Gail can't minus header's height by itself. 

(In reply to comment #11)
> By checking codes of gail and gtk, we consider this may be a gtk's bug.
> 
> In gailtreeview.c, function gail_tree_view_ref_accessible_at_point() computes
> the position (x,y) of whole treeview's widget, and passes x and y directly to
> gtk_tree_view_get_path_at_pos().
> 
> However, gtk_tree_view_get_path_at_pos() assume the position is based on
> priv->bin_window which does not include header_window. For we find
> gtk_tree_view_button_press() has the same code for finding the clicked node,
> which runs well.
> 
> By checking the GtkTreeView's API, we find it impossible to decide header's
> actual height. So Gail can't minus header's height by itself. 

Thanks Yi!  Do you have a recommended way of fixing this?

Just a gentle ping on this one.  :-)

Matthias, from comment #11, we need gtk_tree_view_get_path_at_pos to count header window or an API to get the header window's height.

*** Bug 564943 has been marked as a duplicate of this bug. ***

Created attachment 129038 [details] [review]
patch

Actually we have such function :)