Description of problem: 'Search'->'Go to Line' floating widget can't be caught by sniff. Version-Release number of selected component (if applicable): gedit-2.15.4-1 How reproducible: always Steps to Reproduce: 1.lauched gedit 2.click 'Search'->'Go to Line...' menuitem, floating widget showed in edit area(this floating widget would be invisible in a while automaticly) 3.arbitrary action would make this widget be invisible 4.sniff can't catch this widget, so can't write automatic script to test this widget. Actual results: sniff can't catch this floating widget Expected results: sniff can catch this floating widget Additional info:
Created attachment 135826 [details] gedit screenshot
If this is an a11y issue, every treeview with typeahead search has the same problem (e.g. the file chooser)
Hi Zack, Is this a problem with sniff?
Not really. If you want to figure out how to access that widget via dogtail, and you use sniff to try and do so, it's not currently possible. As soon as you switch your focus back to sniff after clicking Search->Go to line, the widget disappears. If you do the same while the recorder is recording, you'll see that it's an object with roleName='text' and name=''. Not very useful. The only way to find it would be to look at its parent widgets, and see if there's a unique path that you can hop along carefully to get you to that widget. But since any change in focus causes it to go away, you can't be searching for it interactively. You'd have to come up with a script that dumped tons of information about places where you think it *might* be, and hope you're able to find it in the output. The recorder's not even smart enough to do this; any script you record using that widget will most likely fail, because there are so many nameless widgets with the 'text' roleName in gedit. It'd be sweet if it had a name or description field.
So I talked with Zack about this a bit in the grotto today. The concensus is we should close this bug WONTFIX. In the future, zack wants to add a history to sniff to catch cases like this where the window disappears when focus is droppped. Also, there is currently a bug in the recorder right now, where it's not reporting that the entry is in a toplevel of its own, apparently. When that gets fixed, this won't be a problem at all.