GNOME Bugzilla – Bug 551891
Flat review does not always start in the correct place when focus is in a tree table
Last modified: 2008-12-01 18:45:11 UTC
Steps to reproduce: 1. Launch Thunderbird or Evolution 2. Tab to the list messages in your Inbox 3. Up and Down Arrow for good measure 4. Flat review the current line Expected results: Flat review would begin on the line which contains the selected message. Actual results: Flat review begins at the menu bar. What is interesting is that I can only reproduce this problem with the list of messages. I do not have this problem when I perform the above steps using the list of mail folders on the left (in both applications, another tree table). In both cases, the failing tree table has multiple columns and is not the left-most accessible. The Gtk-demo multi-columned tree table example doesn't have this issue, so I'm wondering if for some reason we can't find the zone with focus when the tree table is on the right?
In adition, if I delete a message after flat review the current line, orca doesn't announce the next message This is with intrepid and orca 2.24.
I didn't test with evolution, only with thunderbird.
Created attachment 122350 [details] [review] Fix for Evo There's an additional issue in Thunderbird, but this solves it for Evo. Turned out to be an easy one. Will please review. Thanks!
Created attachment 122357 [details] [review] Includes fix for t-bird Turns out that in Thunderbird we were intentionally setting the locusOfFocus to a cell which in all likelihood had nothing in it (text or image) and also had no name. Thus it was never getting added as a reviewable zone and we were never finding our location.
Way awesome, and looks great. Assuming this tests well, please check it in to trunk and gnome-2-24. Thanks so much!
Thanks Will. It passes the gtk-demo and OOo Writer tests and pylints. Still need to run the FF tests for good measure. We don't have t-bird tests yet. Mike and others, please test. Thanks!
Passes the FF tests.
Joanie, This is working well on my Intrepid box. There is, however, a latency issue. I tested it on two mailboxes. I've been traveling, so one has more than 200 messages that I haven't yet dealt with. It takes about 5 seconds to get a response from pressing numpad-8 when focus is on the first message and about 6 seconds when focus rests on the last message in the mailbox (1.44 GHz processor). In the other mailbox, which has only 6 messages, response time is about 5 seconds for any message with focus. I'm not sure that this latency is the result of this patch, however. The latency appears to be the same when in the mailbox list. Unfortunately, I tried reversing the patch, got all of the appropriate output, and flat review continues to work well. At the moment, I'm too tired to try to figure out what is going on. sorry. Thanks for all the effort!
Sorry, forgot to mention what may be the most important factor in the latency--only 512Mb of RAM in this old box.
Testing with thunderbird in my intrepid box seems to be OK. When scroling in the message list view using the up and down arrow keys, sometimes orca announces what I think to be a garbage before the subject of the message. Sometimes I hear a "subject" without the quotations and sometimes I hear a *. Another observation is that I can not navigate char by char using the numpad-1, numpad-2 and numpad-3. They act exactly as numpad-4, numpad-5 and numpad-6. Thanks.
> Sometimes I hear a "subject" without the quotations and sometimes I hear a *. Before the patch, focus was being placed in a nameless/headerless column. Now it's being placed in the first cell with something in it and that column header being present gets announced. If we shouldn't be announcing column headers there I can take care of that. Mike? > Another observation is that I can not navigate char by char using the > numpad-1, numpad-2 and numpad-3. They act exactly as numpad-4, numpad-5 and > numpad-6. All this patch does is correct the reported bug, namely "flat review does not always start in the correct place when focus is in a tree table." We try to adhere to one problem per bug, otherwise patches become really, really huge and bugs never get fixed. <smile> Therefore, if you could open a new bug for the above issue, that would be great. Thanks!
This patch now seems to be incompatible with Trunk. It seems to conflict with another patch to gecko. If output from the patch command is needed I can provide it.
Created attachment 122857 [details] [review] trunk compatible version The previous patch accidentally included the fix for google calendar (which has since been checked in). Sorry 'bout that.
This patch seems to work nicely in both thunderbird and evolution. I'd say this patch is worth checking in. I have noticed a similar problem in nautilus.. To reproduce do the following: 1. View your home folder in list view. 2. arrow down several files or folders. 3. attempt to flat review the current line. Notice that you are flat reviewing the menubar instead of the current file or folder.
Patch committed to both trunk and the gnome-2-24 branch. Mike, I'm afraid I'm not seeing that problem in Nautilus. I wonder if our settings are different.
It only seems to happen the firs time you arrow down the list. I think once the window scrolls the problem goes away. Debug log incoming.
Created attachment 122886 [details] debug output This output should show the problem.
Created attachment 123246 [details] [review] possible fix for the nautilus issue? If I increase Y by 1 pixel before attempting getAccessibleAtPoint, the problem goes away for me. Mike, does this fix it for you? Will, what's the right thing to do here?
Works fine for me too.
This seems to work for me as well.
(In reply to comment #18) > If I increase Y by 1 pixel before attempting getAccessibleAtPoint, the problem > goes away for me. Mike, does this fix it for you? Will, what's the right thing > to do here? I think this is as OK as anything. The code before the patch is assuming that the accessible children of MANAGES_DESCENDANTS parents will cover the visible surface of the parent. With this assumption, there should be a child at parentExtents.y. However, it looks like this assumption is not quite correct, either due to an off-by-one bug in the accessibility implementation or due to no child actually being there. Since 1-pixel-high visual components are not very common or useful, the +1 operation being performed seems reasonable. I say commit to trunk for today's 2.25.2 release and also to gnome-2-24. Thanks!
Thanks Will. Patch committed to both trunk and the gnome-2-24 branch. It's been "pending" for a while, so closing as FIXED.