GNOME Bugzilla – Bug 568658
sometimes orca announce the wrong subject in thunderbird
Last modified: 2009-06-21 20:43:58 UTC
Please describe the problem: In some situations orca announce the subject of the previous message when scroling in the message list Steps to reproduce: 1. Using thunderbird send to yourself 4 messages. Put different subjects in each message and different text in the body. You can use for example test 1, test 2, test 3 and test 4 for the subject and the body. 2. In the message list locate the message test 3 using the up and down keys. 3. Press the up key two times so that you will land in the test 1 message. 4. Press the delete key. The message is deleted and orca announce the test 2 message as expected. 5. Press down arrow key and note that instead of announce the test 3 message, orca announce the test 2 message again. 6. Press the down arrow key again. Orca should announce test 4 but instead it announces test 3. Actual results: Orca announces the incorrect message Expected results: Does this happen every time? Yes if I execute the steps described. Other information: I'm running Shredder/3.0b2pre
Created attachment 126980 [details] debug file from orca
The problem still exists and I suspect that that it is associated with the use of flat view commands. I am including a new sequence of steps to reproduce the problem Please, pay special attention to the step 5. 1. Start thunderbird. 2. Make sure that the message pane is disabled. 3. send to yourself four messages. The first message must contains the subject test 1, the second message must contains the subject test 2, the third message must contains the subject test 3 and the fourth message must contains the subject test 4. 4. In the message list locate the message test 3 using the up and down keys. 5. Flat review by pressing Caps Lock + i (laptop layout). 6. Press the up key two times so that you will locate the test 1 message. 7. Press the delete key. The message is deleted and orca announce the test 2 message as expected. 8. Press down arrow key and note that instead of announce the test 3 message, orca announce the test 2 message again. 9. Press the down arrow key again. Orca should announce test 4 but instead it announces test 3.
In looking at this, it seems related to pyatspi caching. I added the following two lines to my ~/.orca/user-settings.py file: orca.settings.cacheValues = False orca.settings.cacheDescriptions = False When I conducted the awesome test case (many thanks for that), things worked fine *except* for step #4. In step 4, the test 2 message was not announced. Very odd. I'll dig some more.
I was chatting with Will earlier today about this bug. He asked if it existed prior to the refactor. I didn't know. For part of bug 583811, I needed to work with the gnome-2-26 branch. So for the record, FWIW, yes, this bug did exist prior to the refactor.
Oops The above comment applies to bug 585871. Sorry about that. On this bug Will mentioned that he had questions about something in the T-bird script. Since I'm looking at the t-bird script at the moment, I'd be happy to answer questions. :-)
Created attachment 137114 [details] [review] Address the not-speaking-anything part (In reply to comment #3) > In looking at this, it seems related to pyatspi caching. I added the following > two lines to my ~/.orca/user-settings.py file: > > orca.settings.cacheValues = False > orca.settings.cacheDescriptions = False > > When I conducted the awesome test case (many thanks for that), things worked > fine *except* for step #4. Confirmed. > In step 4, the test 2 message was not announced. Confirmed. > Very odd. Nah. We're just getting bitten (again) by the use of isDesiredFocusedItem. Turns out that an object of ROLE_PANEL has been inserted between the second scroll pane and the frame. This patch stops checking after the second scroll pane and we are no longer silent at step 4. Will, please review. Thanks!
(In reply to comment #6) > Created an attachment (id=137114) [edit] > Address the not-speaking-anything part ... > Nah. We're just getting bitten (again) by the use of isDesiredFocusedItem. Yech. I hate that method. Some day, we will kill it. > Turns out that an object of ROLE_PANEL has been inserted between the second > scroll pane and the frame. This patch stops checking after the second scroll > pane and we are no longer silent at step 4. Looks good to me. I think this is also something worthy of gnome-2.26. If you agree, please submit to both master and gnome-2-26. Many thanks for your work!
I did some digging regarding the cached issue using Accerciser. Here's what I believe is going on: When a cell is first examined (given focus, flat reviewed, queried in Accerciser, etc.), an object:property-change:accessible-name event is emitted *for that cell*. On subsequent examinations of that cell, if the name has changed since the last examination (e.g., because a message has been deleted) an object:property-change:accessible-name event is emitted *for that cell*. Issuing these events only when we need them makes sense to me; otherwise, we're in danger of an event flood each time a message is deleted. When we get a name-changed event, that prompts the dumping of the information cached for the object associated with that event. From pyatspi: ~~~~~~~~~~~ # events that clear cached properties CACHE_EVENTS = ['object:property-change:accessible-name', 'object:property-change:accessible-description', 'object:property-change:accessible-role', 'object:property-change:accessible-parent'] ~~~~~~~~~~~ Now bring in flat review and Jose's test case: (In reply to comment #2) [...] > 5. Flat review by pressing Caps Lock + i (laptop layout). RESULT: As part of building up the flat review context, we examine every cell that's on the screen. We use caching by default. Therefore, the accessible name of each and every cell gets cached by pyatspi. > 6. Press the up key two times so that you will locate the test 1 message. RESULT: Nothing's changed so we present the correct information for the test 1 message. > 7. Press the delete key. The message is deleted and orca announce the > test 2 message as expected. RESULT: We were on row x, we're still on row x. Because the cells of row x no longer have the same name, name-changed events get issued for row x. Pyatspi dumps its cache for the cells on row x as a result. We get fresh information, and present it. Thus things work as expected. > 8. Press down arrow key and note that instead of announce the test 3 message, > orca announce the test 2 message again. RESULT: Orca goes to pyatspi. Pyatspi sees that it already has cached information for the cell -- the result of doing a flat review. Therefore, rather than querying the cell (and thus triggering the name-changed event we need), it returns the cached information. Hence we speak what used to be the contents of row x+1 rather than the current contents. > 9. Press the down arrow key again. Orca should announce test 4 but > instead it announces test 3. RESULT: (same as before) If at this point you do a flat review and then arrow around, Orca once again presents the correct information. So there is that work-around. Will, what do you think we should do in this case? I don't think this is a tbird bug (i.e. we don't want to get flooded with events). If we "tickle the hierarchy" in Orca to get the updated information for the table each time a message is deleted, that will not be performant. So maybe things should be changed in pyatspi. However, to me, it seems rather extreme (and perhaps not very performant) for pyatspi to dump its entire table cache just because one cell issued a name-changed event. I thought maybe dumping the entire table cache might be worth considering if we got children-changed events. However, tbird isn't issuing them and pyatspi doesn't currently dump the cache even if tbird were.
(In reply to comment #7) > Looks good to me. I think this is also something worthy of gnome-2.26. If you > agree, please submit to both master and gnome-2-26. Done.
Created attachment 137119 [details] [review] Dump the cache (only) if we are in tbird and leave flat review I'm not saying we should do this. That said, this patch is limited to the Thunderbird script and solves the problem. Failing this, I am at a loss as to what we can do.
(In reply to comment #10) > Created an attachment (id=137119) [edit] > Dump the cache (only) if we are in tbird and leave flat review > > I'm not saying we should do this. That said, this patch is limited to the > Thunderbird script and solves the problem. So....I went for a ride in the rain and came back thinking this same thing. I think this is fine and say commit to gnome-2-26 and master. Many thanks for digging into this one.
(In reply to comment #11) > So....I went for a ride in the rain and came back thinking this same thing. <strike>Waterlogged</strike> great minds think alike? ;-) > think this is fine and say commit to gnome-2-26 and master. Done. Thanks!