GNOME Bugzilla – Bug 515665
Orca has problems with tables that have captions in FF3
Last modified: 2009-03-10 00:04:48 UTC
This is a tracking bug for the following Firefox bug which seems to have been introduced in the 7 Feb build. Regression: Table caption interferes with getColumnAtIndex() https://bugzilla.mozilla.org/show_bug.cgi?id=416742
For the sake of documentation, the blocking bug has been marked as FIXED as of a few days ago. I just built FF from source and the original problem I reported persists. :-( I haven't reopened the bug (yet), but have commented hoping for some insight.
More "documentation": Bernd has asked me to produce a mochitest illustrating the erroneous results. Since their existing mochitest does an excellent job of that already (from our perspective, i.e. using Orca and Accerciser), and since I'm not familiar with their testing framework.... :-( But on the bright side, Bernd pointed me at a good resource and I should have some "hacking time" with Marco and potentially others at CSUN. So I'm going to leave the blocking bug closed and try to sort out mochitests....
Just a gentle nudge on this one as a reminder that they might still be waiting for info from us.
Marking as unblocked because the FF guys implemented an object attribute we can use as a work-around.
Created attachment 110697 [details] [review] revision 1 Seems to get the job done in terms of functional testings. Pylints to 10's. I need to run all of the regression tests.
The results with the patch and without are the same for gtk-demo, oowriter, and oocalc. Mike please test. Will please review. Thanks.
This seems OK, though I thnk I would have expctd to see all ocrncs of getIndexInParent to be rplcd with getCellIndex whenever a tbl cell was involved. When I ex the fls in this lst, I don't see chngs for all the fls: find . -name \*.py | xargs grep getIndexInPar | cut -f1 -d: | sort -u PS - the abbrevs above are a lame attempt at humor for noticing the change of 'coordinates' to 'coords' in the patch. :-)
This seems to work nicely
Created attachment 111081 [details] [review] revision 2 (In reply to comment #7) > This seems OK, though I thnk I would have expctd to see all ocrncs of > getIndexInParent to be rplcd with getCellIndex whenever a tbl cell was > involved. When I ex the fls in this lst, I don't see chngs for all the fls: True. And I admittedly hadn't thought to make all of those changes. Oops. The thing is.... Sometimes we really want the index in parent, even for a table cell. Maybe for object navigation, maybe for comparison, maybe for iterating through children... As I started changing things, I kept running across instances where I just wasn't sure what the potential side effect of the change might be. So then I figured that since the problem was specific to table.get{Row,Column}AtIndex(), I could make a getCellCoordinates() to do this work. That, too, touched quite a bit of code. And while I thought I understood all the potential side effects, regression testing proved otherwise. :-) So.... This version goes back to plan A. But I did go through all of the code, replacing foo.getIndexInParent() with getCellIndex(foo) any time the former was the argument passed to table.get{Row,Column}AtIndex(). Fewer changes and it seems to regression test well. :-) > PS - the abbrevs above are a lame attempt at humor for noticing the change of > 'coordinates' to 'coords' in the patch. :-) Ah. I thought it was your learning grade 2 braille and/or trying to communicate your thoughts within the confines of 140 characters. :-) It's back to being coordinates. Please review.
Patch committed to trunk. Moving to pending.
Per team meeting, we're closing this one as FIXED.
Created attachment 111870 [details] [review] tweak to include tree tables Tree tables need to be dealt with.... My bad. Already committed to trunk.