Bug 205710

Summary:

'Go to Line' floating widget can't be caught by sniff.

Product:

Red Hat Enterprise Linux 5

Reporter:

Yan Tian <tyan>

Component:

gedit

Assignee:

Ray Strode [halfline] <rstrode>

Status:

CLOSED WONTFIX

QA Contact:

David Lawrence <dkl>

Severity:

medium

Docs Contact:

Priority:

medium

Version:

5.0

CC:

zcerza

Target Milestone:

---

Target Release:

---

Hardware:

i386

OS:

Linux

Whiteboard:

Fixed In Version:

Doc Type:

Bug Fix

Doc Text:

Story Points:

---

Clone Of:

Environment:

Last Closed:

2006-10-12 21:10:28 UTC

Type:

---

Regression:

---

Mount Type:

---

Documentation:

---

CRM:

Verified Versions:

Category:

---

oVirt Team:

---

RHEL 7.3 requirements from Atomic Host:

Cloudforms Team:

---

Target Upstream Version:

Embargoed:

Bug Depends On:

Bug Blocks:

169147

Attachments:

Description	Flags
gedit screenshot	none

Description Yan Tian 2006-09-08 03:21:11 UTC

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-08 03:27:51 UTC

Created attachment 135826 [details]
gedit screenshot

Comment 3 Matthias Clasen 2006-10-12 01:23:18 UTC

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 15:55:36 UTC

Hi Zack,

Is this a problem with sniff?

Comment 5 Zack Cerza 2006-10-12 16:31:49 UTC

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 21:10:28 UTC

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.