GNOME Bugzilla – Bug 517505
Orca doesn't present new active descendant when deleting from the top of a list
Last modified: 2008-02-28 20:50:59 UTC
Steps to reproduce: 1) Fill a temporary directory with several items, and open that directory in Nautilus. You also need some settings in Nautilus that differ from the default: Edit->Preferences->Behavior: [ ] Ask before emptying the Trash or deleting files [x] Include a Delete command that bypasses Trash View->View as List 2) Arrow to the top of the file listing. 3) Pressed Shift+F10 followed by 'D' to delete the top item in the file list Expected results: Orca would present the new item that is now the highlighted/selected item. Actual results: Orca presents the window title, which you may not always hear because it seems to be cut off by a speech.stop() somewhere.
Note also that if you delete from the bottom of the list upwards, we seem to get the desired behavior. I suspect the problem it that we have code that saves away the old active descendant, remembering its index in the parent. In this case, the new active descendant's index in the parent is the same as the old one because we've just deleted the old one. No thought given on fixing this one yet. :-)
Will hit it right on the head. There is a section of code in the isSameObject() method in default.py that looks like: # When we're looking at children of objects that manage # their descendants, we will often get different objects # that point to the same logical child. We want to be able # to determine if two objects are in fact pointing to the # same child. # If we cannot do so easily (i.e., object equivalence), we examine # the hierarchy and the object index at each level. # parent1 = obj1 parent2 = obj2 while (parent1 and parent2 and \ parent1.getState().contains( \ pyatspi.STATE_TRANSIENT) and \ parent2.getState().contains(pyatspi.STATE_TRANSIENT)): if parent1.getIndexInParent() != parent2.getIndexInParent(): return False parent1 = parent1.parent parent2 = parent2.parent if parent1 and parent2 and parent1 == parent2: return True If I create a directory called "testarea" with three files in it called "file1", "file2" and "file3", then move to the top of the list and press Shift-F10 and "d", when isSameObject() is called, it's returning with that last "return True". If I comment out that chunk of code above, and reset up the test directory and the three files and repeat the experiment, then Orca nicely brailles/speaks "file2" after "file1" has been deleted. So what should we do here? Thoughts?
Just took a quick look because I was curious as to why we were getting that far down into isSameObject(). I would have thought that obj1.name would not equal obj2.name and that, as a result, we'd have bailed already. After adding some debugging code to isSameObject(), it looks like obj1 and obj2 are table cells which are ancestors of the real things we care about (namely file1, file2, and so on). If I get the realActiveDescendant of obj1 and obj2 and compare those, we seem to speak the right thing. Just a "lunch time thought" rather than anything I've pondered or tested thoroughly. <shrugs>
> I would have thought that obj1.name would not equal > obj2.name and that, as a result, we'd have bailed already. They are both empty strings. Sigh. Maybe the accessible names should be the actual file names... > After adding some debugging code to isSameObject(), it looks like obj1 > and obj2 are table cells which are ancestors of the real things we care > about (namely file1, file2, and so on). Sorry, I'm confused. The ancestry at this particular point is: +- app.name='nautilus' name='nautilus' role='application' state='' relations='' +- app.name='nautilus' name='testarea - File Browser' role='frame' state='active enabled resizable sensitive showing visible' relations='' +- app.name='nautilus' name='None' role='panel' state='enabled sensitive showing visible' relations='' +- app.name='nautilus' name='None' role='split pane' state='enabled focusable horizontal sensitive showing visible' relations='' +- app.name='nautilus' name='None' role='filler' state='enabled sensitive showing vertical visible' relations='' +- app.name='nautilus' name='None' role='filler' state='enabled sensitive showing vertical visible' relations='' +- app.name='nautilus' name='Content View' role='scroll pane' state='enabled focusable sensitive showing visible' relations='' +- app.name='nautilus' name='List View' role='table' state='enabled focusable focused sensitive showing visible manages descendants' relations='' +- app.name='nautilus' name='None' role='table cell' state='defunct enabled focusable selectable sensitive showing transient visible' relations='node child of' What are the ancestors that we really care about? Would using realActiveDescendant be something we can use in every case? Anyhoo, I have a potential hack (um, solution). Just testing it now.
> They are both empty strings. Sigh. Maybe the accessible names should be the > actual file names... Well, there are indeed accessibles whose names are the actual file names. :-) The problem, looking in Accerciser seems to be this: Size: table cell with name of "0 bytes" (or whatever) Type: table cell with name of "unknown" (or whatever) Date: table cell with name of "wed 27 feb..." (or whatever) So far so good, but: Name: table cell with name of an empty string (as you pointed out) This table cell has two children, the first of which is a table cell which also seems to be nameless. The second child, however, is a table cell with the name "file1" (or whatever). > Sorry, I'm confused. The ancestry at this particular point is: is not very helpful because of the lack of names, I think. Going up doesn't tell us anything. It's the children which do (I think): If we get the real active descendant of obj1 and the real active descendant of obj2 we wind up with an accessible whose name is "file1" (or whatever) and another whose name is "file2" (or whatever). My theory/suggestion was that a comparison on these two objects might be handy. > What are the ancestors that we really care about? Uh..... None of 'em? :-) > Would using realActiveDescendant be something we can use in every case? That I'm not so sure about. But a quick glance at the code makes me think you might could try it just before doing the bit which causes us to return True. > Anyhoo, I have a potential hack (um, solution). Just testing it now. Okay, then potentially never mind. ;-) Good luck!
> Okay, then potentially never mind. ;-) Good luck! Well my hack is ugly, so I'm going to try out your suggest approach. Thanks.
Created attachment 106094 [details] [review] Revision #1 Well I tried what I think you are suggesting Joanie, but the role_table.py regression test went kablooey, so I'm going to see if I can just add something to the nautilus script that captures this one isolated case.
Created attachment 106096 [details] Regression tests results for gtk-demo role_table.py without patch. Looks like the results of running this regression test without my patch are hosed anyway (see attached). Joanie suggested a slight modification to my previous patch, so I'm going to try that and if it works attach a new patch.
Created attachment 106098 [details] [review] Revision #2 This seems to nicely fix the problem. Please test.
I tried it with Nautilus, Evo, and Tbird just now -- quick tests because I'm in the middle of DayJob stuff. That said, it indeed seems to fix the problem in Nautilus. Thunderbird isn't doing the right thing all of the time, but that is true without your patch (and may be related to the tree changes and bugs that are currently active on the tbird front). Because our FF support lives and dies by isSameObject() doing the right thang, I am running the FF regression tests using your patch. I'm not expecting regressions looking at the patch, but I'll sleep better knowing that this has been verified. :-) They take a bit over an hour to run. Stay tuned.
Assuming the patch is good, i think this patch should also be applied to the GNOME 2.22 branch. Mike could you test it please? Will could you comment on whether the change it good from a code review perspective please? Thanks.
No FF regressions as a result of your patch.
(In reply to comment #11) > Will could you comment on whether the change it good from a code review > perspective please? OK - thinking out loud... The bulk of the patch is this change in isSameObject. If this is True at the particular state where we are in the code, we assume the objects passed into the method are the same object: + return self.getRealActiveDescendant(obj1).name == \ + self.getRealActiveDescendant(obj2).name So, I then wonder if getRealActiveDescendant has any preconditions on the object passed in (e.g., must it be something related to things that manage their descendants?). The docs for getRealActiveDescendant seem to say so: - obj: an object that should be a child of an object that manages its descendants. Hmm...what happens if we violate that anyway? The code seems to provide some defensive measures for this, but it's not complete and we can get back the last child of the object passed in (i.e., obj[-1] as is done in the code). So...in the worst case, we might end up comparing the names of obj1[-1] and obj2[-1]. Can we end up in a case where we have a hierarchy that looks something like this and ends up giving us a false positive? +- parent1 (which also == parent2) +- obj1(name="blah") +- somechild1(name="foo") +- obj2(name="blah") +- somechild2(name="foo") I'm not sure of the answer. Looks like it *might* be feasible, but not probable. In the case where we do run into this improbable behavior, what is the result going to be? I'm not sure of that, either. Then again, it was a false positive that got us to this bug in the first place. ;-) So, I shrug. isSameObject is never going to be bullet proof. Joanie's FF test results give me some comfort. :-) Have you run ALL of the gtk-demo tests as a sanity check?
Created attachment 106116 [details] Results of running the gtk-demo regression tests WITH patch applied. > Have you run ALL of the gtk-demo tests as a sanity check? I have now. This is on Ubuntu Hardy. Here's the summary of the SUMMARY's: SUMMARY: 0 SUCCEEDED and 1 FAILED (1 UNEXPECTED) of 1 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/debug_commands.py SUMMARY: 6 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 6 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/learn_mode.py SUMMARY: 7 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 7 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_accel_label.py SUMMARY: 1 SUCCEEDED and 2 FAILED (2 UNEXPECTED) of 3 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_alert.py SUMMARY: 14 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 14 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_check_box.py SUMMARY: 2 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_check_menu_item.py SUMMARY: 6 SUCCEEDED and 4 FAILED (4 UNEXPECTED) of 10 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_column_header.py SUMMARY: 0 SUCCEEDED and 4 FAILED (4 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_combo_box2.py SUMMARY: 11 SUCCEEDED and 4 FAILED (4 UNEXPECTED) of 15 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_combo_box.py SUMMARY: 2 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_dialog.py SUMMARY: 3 SUCCEEDED and 4 FAILED (0 UNEXPECTED) of 7 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_icon.py SUMMARY: 4 SUCCEEDED and 5 FAILED (0 UNEXPECTED) of 9 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_label.py SUMMARY: 8 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 8 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_menu.py SUMMARY: 2 SUCCEEDED and 2 FAILED (2 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_page_tab.py SUMMARY: 4 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_push_button.py SUMMARY: 3 SUCCEEDED and 2 FAILED (0 UNEXPECTED) of 5 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_radio_button.py SUMMARY: 4 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_radio_menu_item.py SUMMARY: 3 SUCCEEDED and 4 FAILED (0 UNEXPECTED) of 7 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_spin_button.py SUMMARY: 0 SUCCEEDED and 4 FAILED (0 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_split_pane.py SUMMARY: 1 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 1 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_status_bar.py SUMMARY: 1 SUCCEEDED and 6 FAILED (6 UNEXPECTED) of 7 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_table.py SUMMARY: 2 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_tear_off_menu_item.py SUMMARY: 94 SUCCEEDED and 5 FAILED (5 UNEXPECTED) of 99 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation.py SUMMARY: 10 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 10 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline.py SUMMARY: 5 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 5 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_toggle_button.py SUMMARY: 6 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 6 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_toolbar.py SUMMARY: 6 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 6 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_tooltip.py SUMMARY: 11 SUCCEEDED and 3 FAILED (0 UNEXPECTED) of 14 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_tree_table.py SUMMARY: 1 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 1 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_window.py I'll run them again now without that patch applied. As they take almost forty minutes it's going to be a while...
Created attachment 106120 [details] Results of running the gtk-demo regression tests WITHOUT the patch applied. No difference in the summary of SUMMARY's: SUMMARY: 0 SUCCEEDED and 1 FAILED (1 UNEXPECTED) of 1 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/debug_commands.py SUMMARY: 6 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 6 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/learn_mode.py SUMMARY: 7 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 7 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_accel_label.py SUMMARY: 1 SUCCEEDED and 2 FAILED (2 UNEXPECTED) of 3 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_alert.py SUMMARY: 14 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 14 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_check_box.py SUMMARY: 2 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_check_menu_item.py SUMMARY: 6 SUCCEEDED and 4 FAILED (4 UNEXPECTED) of 10 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_column_header.py SUMMARY: 0 SUCCEEDED and 4 FAILED (4 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_combo_box2.py SUMMARY: 11 SUCCEEDED and 4 FAILED (4 UNEXPECTED) of 15 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_combo_box.py SUMMARY: 2 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_dialog.py SUMMARY: 3 SUCCEEDED and 4 FAILED (0 UNEXPECTED) of 7 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_icon.py SUMMARY: 4 SUCCEEDED and 5 FAILED (0 UNEXPECTED) of 9 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_label.py SUMMARY: 8 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 8 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_menu.py SUMMARY: 2 SUCCEEDED and 2 FAILED (2 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_page_tab.py SUMMARY: 4 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_push_button.py SUMMARY: 3 SUCCEEDED and 2 FAILED (0 UNEXPECTED) of 5 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_radio_button.py SUMMARY: 4 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_radio_menu_item.py SUMMARY: 3 SUCCEEDED and 4 FAILED (0 UNEXPECTED) of 7 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_spin_button.py SUMMARY: 0 SUCCEEDED and 4 FAILED (0 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_split_pane.py SUMMARY: 1 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 1 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_status_bar.py SUMMARY: 1 SUCCEEDED and 6 FAILED (6 UNEXPECTED) of 7 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_table.py SUMMARY: 2 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 2 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_tear_off_menu_item.py SUMMARY: 94 SUCCEEDED and 5 FAILED (5 UNEXPECTED) of 99 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation.py SUMMARY: 10 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 10 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline.py SUMMARY: 5 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 5 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_toggle_button.py SUMMARY: 6 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 6 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_toolbar.py SUMMARY: 6 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 6 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_tooltip.py SUMMARY: 11 SUCCEEDED and 3 FAILED (0 UNEXPECTED) of 14 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_tree_table.py SUMMARY: 1 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 1 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_window.py I'd say the patch isn't affecting the gtk-demo regression tests.
Created attachment 106128 [details] jd's results of running the gtk-demo regression tests WITH patch applied Here's mine for good measure. At least with the patch applied. Seeing as how Rich has established that the patch doesn't seem to impact the results, I'm not going to do a before and after comparison.
I went ahead and ran them too -- just with the patch, however, since Rich has already established that the patch does not seem to be changing the results. The tests were run on my laptop with the latest (current as of the moment) Hardy. Since there is lots of output to look at and compare here, I'll do these in chunks. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RB: SUMMARY: 0 SUCCEEDED and 1 FAILED (1 UNEXPECTED) of 1 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/debug_commands.py JD: SUMMARY: 0 SUCCEEDED and 1 FAILED (1 UNEXPECTED) of 1 for /home/jd/orca/test/keystrokes/gtk-demo/debug_commands.py Rich and I seem to have the same version of gail (1.21.5) whereas the test expects an earlier version (1.20.0) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RB: SUMMARY: 1 SUCCEEDED and 2 FAILED (2 UNEXPECTED) of 3 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_alert.py JD: SUMMARY: 3 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 3 for /home/jd/orca/test/keystrokes/gtk-demo/role_alert.py Hmmmm.... Rich, what did you break? ;-) <Looking at the output Rich attached> Aha! I've seen that sort of thing before with these tests. It looks like Rich timed out (whereas I didn't). Rich, if you run this one test manually, does it persist in failing for you? ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RB: SUMMARY: 6 SUCCEEDED and 4 FAILED (4 UNEXPECTED) of 10 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_column_header.py JD: SUMMARY: 6 SUCCEEDED and 4 FAILED (4 UNEXPECTED) of 10 for /home/jd/orca/test/keystrokes/gtk-demo/role_column_header.py Another match. For the tests that fail it seems that we're both seeing "not selected" (or rather " not selected") at the end of the context for the cells. My guess would be that this is the result of those recent changes made to Gtk/Gail (at our request) so that we could provide the user with info related to the selected/unselected state of items in a multi-select environment. Will, if you're not seeing this as well, are you not using the latest Gtk (or Gail)? If we're all using the same version, then I dunno.... I'd have to look closer at the tests to see if the addition of "not selected" in these four tests is desirable. I'll leave that for another evening. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RB: SUMMARY: 0 SUCCEEDED and 4 FAILED (4 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_combo_box2.py JD: SUMMARY: 0 SUCCEEDED and 4 FAILED (4 UNEXPECTED) of 4 for /home/jd/orca/test/keystrokes/gtk-demo/role_combo_box2.py We have a winner. Looking at our respective (and quite similar) outputs for this test, but not delving into the actual tests, I'm guessing one of two things (or both): 1. Rich and I each have a printer set up and Will does not. 2. The printer dialog has changed and we have a version that Will does not. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ End of chunk 1.
Chunk 2 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RB: SUMMARY: 11 SUCCEEDED and 4 FAILED (4 UNEXPECTED) of 15 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_combo_box.py JD: SUMMARY: 11 SUCCEEDED and 4 FAILED (4 UNEXPECTED) of 15 for /home/jd/orca/test/keystrokes/gtk-demo/role_combo_box.py Our output matches. I'd have to take a closer look at the test (and potentially an older version of gtk-demo) to see if the dialog box in question had changed. It seems that the difference in the expected and actual results is that we're in a slightly different place than the test thinks we should be. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RB: SUMMARY: 2 SUCCEEDED and 2 FAILED (2 UNEXPECTED) of 4 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_page_tab.py JD: SUMMARY: 2 SUCCEEDED and 2 FAILED (2 UNEXPECTED) of 4 for /home/jd/orca/test/keystrokes/gtk-demo/role_page_tab.py Rich and I don't match *exactly* here, but the pattern is the same. EXPECTED: "BRAILLE LINE: 'gtk-demo Application Print Dialog General Page'", " VISIBLE: 'General Page', cursor=1", "SPEECH OUTPUT: 'tab list'", "SPEECH OUTPUT: 'General page'", "SPEECH OUTPUT: 'item 1 of 2'", "SPEECH OUTPUT: ''", RB ACTUAL: "BRAILLE LINE: 'gtk-demo Application Print Dialog General Page'", " VISIBLE: 'General Page', cursor=1", "SPEECH OUTPUT: 'tab list'", "SPEECH OUTPUT: 'General page'", "SPEECH OUTPUT: 'item 1 of 4'", "SPEECH OUTPUT: ''", JD ACTUAL: "BRAILLE LINE: 'gtk-demo Application Print Dialog General Page'", " VISIBLE: 'General Page', cursor=1", "SPEECH OUTPUT: 'tab list'", "SPEECH OUTPUT: 'General page'", "SPEECH OUTPUT: 'item 1 of 5'", "SPEECH OUTPUT: ''", So.... I assume that Rich and I share the same dialog (which is different from that in the test) and that I have a printer set up on this box which Rich does not. ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Chunk 3 (the final episode) ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RB: SUMMARY: 1 SUCCEEDED and 6 FAILED (6 UNEXPECTED) of 7 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_table.py JD: SUMMARY: 1 SUCCEEDED and 6 FAILED (6 UNEXPECTED) of 7 for /home/jd/orca/test/keystrokes/gtk-demo/role_table.py Oh yeah.... This test.... My guess is that this demo changed. I haven't been able to match the expected results for a while. See http://bugzilla.gnome.org/show_bug.cgi?id=486897#c18 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ RB: SUMMARY: 94 SUCCEEDED and 5 FAILED (5 UNEXPECTED) of 99 for /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation.py JD: SUMMARY: 95 SUCCEEDED and 4 FAILED (4 UNEXPECTED) of 99 for /home/jd/orca/test/keystrokes/gtk-demo/role_text_multiline_navigation.py Ha! I win 95 to 94!!! ;-) Test 89 of 99 FAILED: /home/jd/orca/test/keystrokes/gtk-demo/role_text_multiline_navigation.py:Shift+Ctrl+Page_Down to select text to end of line Test 89 of 99 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation.py:Shift+Ctrl+Page_Down to select text to end of line Test 90 of 99 FAILED: /home/jd/orca/test/keystrokes/gtk-demo/role_text_multiline_navigation.py:Shift+Up to select text Test 90 of 99 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation.py:Shift+Up to select text Test 91 of 99 FAILED: /home/jd/orca/test/keystrokes/gtk-demo/role_text_multiline_navigation.py:Shift+Down to deselect text Test 91 of 99 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation.py:Shift+Down to deselect text Test 93 of 99 FAILED: /home/jd/orca/test/keystrokes/gtk-demo/role_text_multiline_navigation.py:Ctrl+Page_Down to end of line Test 93 of 99 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation.py:Ctrl+Page_Down to end of line I wonder if the differences here are similar to the Solaris-Ubuntu whitespace differences we've discussed (but not gotten to the bottom of, afaik)? That leaves Rich's additional failure: ------------------------- Test 87 of 99 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation.py:KP_Divide to left click on 'l' EXPECTED: "BRAILLE LINE: 'This is only $l'", " VISIBLE: 'This is only $l', cursor=11", "BRAILLE LINE: 'This is only $l'", " VISIBLE: 'This is only $l', cursor=11", ACTUAL: "BRAILLE LINE: 'This is only $l'", " VISIBLE: 'This is only $l', cursor=11", "BRAILLE LINE: 'This is only $l'", " VISIBLE: 'This is only $l', cursor=11", "BRAILLE LINE: 'This is only $l'", " VISIBLE: 'This is only $l', cursor=11", "SPEECH OUTPUT: 'This'", "SPEECH OUTPUT: 'selected'", ------------------------- *shrugs* ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ That's all folks. My output seems to match Rich's quite closely. We need to find a way to get more reliably reproducible (consistent across all platforms) tests -- or a way to add support into the harness to tolerate differences across platforms.
> RB: > SUMMARY: 1 SUCCEEDED and 2 FAILED (2 UNEXPECTED) of 3 for > /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_alert.py > > JD: > SUMMARY: 3 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 3 for > /home/jd/orca/test/keystrokes/gtk-demo/role_alert.py > > Hmmmm.... Rich, what did you break? ;-) > > <Looking at the output Rich attached> Aha! I've seen that sort of thing before > with these tests. It looks like Rich timed out (whereas I didn't). Rich, if > you run this one test manually, does it persist in failing for you? Yes.
The role_alert.py regression test is working fine for me now: $ ./runone.sh ../keystrokes/gtk-demo/role_alert.py gtk-demo 0 starting test application gtk-demo ... Test 1 of 3 SUCCEEDED: ../keystrokes/gtk-demo/role_alert.py:Information Alert automatic presentation Test 2 of 3 SUCCEEDED: ../keystrokes/gtk-demo/role_alert.py:Interactive Dialog no automatic presentation Test 3 of 3 SUCCEEDED: ../keystrokes/gtk-demo/role_alert.py:Interactive Dialog Where Am I SUMMARY: 3 SUCCEEDED and 0 FAILED (0 UNEXPECTED) of 3 for ../keystrokes/gtk-demo/role_alert.py /usr/bin/orca: line 92: 15277 Killed /usr/bin/python -c "import orca.orca; orca.orca.main()" "$ARGS" ./runone.sh: line 187: 15284 Killed $APP_NAME $ARGS $PARAMS $ The fix? Running Preferences->Windows and making sure that the "Select windows when the mouse moves over them" checkbox wasn't checked. So apart from Test 87 of 99 FAILED: /home/richb/gnome/orca/trunk/test/keystrokes/gtk-demo/role_text_multiline_navigation.py:KP_Divide to left click on 'l' EXPECTED: "BRAILLE LINE: 'This is only $l'", " VISIBLE: 'This is only $l', cursor=11", "BRAILLE LINE: 'This is only $l'", " VISIBLE: 'This is only $l', cursor=11", ACTUAL: "BRAILLE LINE: 'This is only $l'", " VISIBLE: 'This is only $l', cursor=11", "BRAILLE LINE: 'This is only $l'", " VISIBLE: 'This is only $l', cursor=11", "BRAILLE LINE: 'This is only $l'", " VISIBLE: 'This is only $l', cursor=11", "SPEECH OUTPUT: 'This'", "SPEECH OUTPUT: 'selected'", ------------------------- I believe we are now at just the differences between Will's Solaris GNOME 2.20 + latest AT system vs Rich/Joanie's almost GNOME 2.22 Ubuntu Hardy system's (with printers).
Created attachment 106185 [details] alternative mini multi-line test Cool Rich. Because the remaining unexpected failure we have in difference is item 87 of a 99 item test, I thought it might be helpful to isolate what's being tested. The attached only has 5 items and is more or less the same thing being tested. I get all successes when I run this on my hardy laptop. Do you see a difference?
If this passes the updated tests it seems to work great for me.
If the UNEXPECTED failures you're seeing are not caused by this patch, and you are comfortable with this patch, then I guess it's OK to check it in. I'm a little nervous about it since it touches a sensitive part of the code, but my comments in lucky comment #13 still stand. So as not to cloud this bug with a separate issue, I opened two new bugs this morning: Bug 519271 - Regression tests need work Bug 519274 - Need nightly runs of the regression tests I think the work to resolve the unexpected failures should happen in bug 519271 and this bug should focus on the original problem of "Orca doesn't present new active descendant when deleting from the top of a list". Thanks!
Patch committed to SVN trunk and the gnome-2-22 branch. Closing as FIXED. I'll work with Joanie in bug #519271 on the regression test anomalies (that are currently present with or without the patch for this bug). Thanks everyone.