Bug 205710 - 'Go to Line' floating widget can't be caught by sniff.
'Go to Line' floating widget can't be caught by sniff.
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: gedit (Show other bugs)
5.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
David Lawrence
:
Depends On:
Blocks: 169147
  Show dependency treegraph
 
Reported: 2006-09-07 23:21 EDT by Yan Tian
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-10-12 17:10:28 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
gedit screenshot (27.09 KB, image/png)
2006-09-07 23:27 EDT, Yan Tian
no flags Details

  None (edit)
Description Yan Tian 2006-09-07 23:21:11 EDT
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:
Comment 1 Yan Tian 2006-09-07 23:27:51 EDT
Created attachment 135826 [details]
gedit screenshot
Comment 3 Matthias Clasen 2006-10-11 21:23:18 EDT
If this is an a11y issue, every treeview with typeahead search has the same
problem (e.g. the file chooser)
Comment 4 Ray Strode [halfline] 2006-10-12 11:55:36 EDT
Hi Zack,

Is this a problem with sniff?
Comment 5 Zack Cerza 2006-10-12 12:31:49 EDT
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.
Comment 6 Ray Strode [halfline] 2006-10-12 17:10:28 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.