Please describe the problem:
When swapping rows within a table, the cells' accessible info (name/description) is placed incorrectly.  Instead of being reassigned to the new indices, it is placed at table row[0] regardless of actual index (successfully skipping table headers, but to wrong index).

The canonical approach of swapping table cells is outlined in the PyGtk FAQ:
http://www.async.com.br/faq/pygtk/index.py?req=show&file=faq13.030.htp

The approach is outlined here, an example that moves a given row up (in a single-column list):
 def button_clicked_cb(button, model):
   selection = model.get_selection()
   model, selected = selection.get_selected()
   assert not selected is None
   path = model.get_path(selected)
   row = path[0]
   assert row > 0
   this = model[row][0]
   prev = model[row-1][0]
   model[row-1][0] = this
   model[row][0] = prev
   selection.select_path(row-1)

In my tests within python storing a list of strings in a list store (the 'model), we find that 'this' and 'prev' are just strings, the names of the items in the list.  Moving them in python prevents us from knowing what happens at the gail layer, but we wouldn't be surprised if the items were not updated in ATSPI.  However, using at-poke, we find that the table items are indeed updated, but to the wrong index.

Steps to reproduce:
1. Run at-poke on an application using the code supplied above
2. Assign accessible name/description to all table row items
3. Call the method above
4. Watch as the table rows are moved, but their at-spi names/descriptions are moved to incorrect indices.  Specifically, the accessible name/desc for the item moved upwards are written to the first item in the table, regardless of where that item was moved from.


Actual results:
at-spi names/descriptions are moved to incorrect indices.  Specifically, the accessible name/desc for the item moved upwards are written to the first item in the table, regardless of where that item was moved from.


Expected results:
at-spi names/descriptions should be moved to their correct indices, matching the new displayed position of the table item.


Does this happen every time?
Yes

Other information:
Perhaps there is a issue with gailcontainercall.c::_gail_container_cell_recompute_child_indices() ??