After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 667047 - Gedit's status bar is no longer accessible
Gedit's status bar is no longer accessible
Status: RESOLVED OBSOLETE
Product: gedit
Classification: Applications
Component: general
3.4.x
Other Linux
: Normal normal
: ---
Assigned To: Gedit maintainers
Gedit maintainers
Depends on:
Blocks:
 
 
Reported: 2011-12-30 20:52 UTC by Joanmarie Diggs (IRC: joanie)
Modified: 2020-11-24 10:00 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
test script which looks for and prints out accessible status bar info (742 bytes, text/plain)
2012-04-09 13:29 UTC, Joanmarie Diggs (IRC: joanie)
Details

Description Joanmarie Diggs (IRC: joanie) 2011-12-30 20:52:59 UTC
According to Accerciser, in F16 Gedit's status bar has no name, no accessible text, and no children. More research will be needed to determine exactly where things broke and then file a bug in the appropriate component. But if Orca cannot see any information about a widget, it sure as heck cannot present it.
Comment 1 Joanmarie Diggs (IRC: joanie) 2012-04-09 13:29:00 UTC
Created attachment 211640 [details]
test script which looks for and prints out accessible status bar info

Using the attached test script, I gave focus to the following three windows:

1. gtk3-demo's application window
2. nautilus
3. gedit

In all three cases I can see a status bar on screen. The results:

~~~~~~~~~~~~~~~
[frame | Application Window] from [application | gtk3-demo] has 1 status bars
Name: Cursor at row 0 column 0 - 3 chars in document
Text: (text iface not implemented)
Child count: 0

[frame | Home] from [application | nautilus] has 1 status bars
Name: "Documents" selected (containing 0 items), Free space: 166.0 GB
Text: (text iface not implemented)
Child count: 0

[frame | Unsaved Document 2 - gedit] from [application | gedit] has 1 status bars
Name: 
Text: (text iface not implemented)
Child count: 0
~~~~~~~~~~~~~~~

In the case of gedit, we can find the status bar, but:

* It doesn't have an accessible name (like the others)

* It doesn't implement the accessible text interface
  (an alternative means to get us the information)

* It does not have any accessible children
  (e.g. labels whose name or text could provide the information)
Comment 2 Jose Vilmar Estacio de Souza 2012-04-09 15:30:50 UTC
Using the attached script, I found the following for eclipse:

[frame | Java - sw/src/sw/SWFieldGroupRed.java - Eclipse ] from [application | Eclipse] has 1 status bars
Name: 
Text: 
Child count: 9
Comment 3 Joanmarie Diggs (IRC: joanie) 2012-04-09 15:52:05 UTC
(In reply to comment #2)
> Using the attached script, I found the following for eclipse:
> 
> [frame | Java - sw/src/sw/SWFieldGroupRed.java - Eclipse ] from [application |
> Eclipse] has 1 status bars
> Name: 
> Text: 
> Child count: 9

Not sure I get the relevance. If you are saying that Orca is not presenting the status bar in Eclipse, please open a bug against Orca. (This bug here is filed against Gedit.) If on the other hand, your point is that there are different accessible hierarchies to status bars and sometimes it is the children which contain the information we need, then, yes, you are correct. :)
Comment 4 Sébastien Wilmet 2020-11-24 10:00:00 UTC
Mass-closing of all gedit bugzilla tickets.

Special "code" to find again all those gedit bugzilla tickets that were open before the mass-closing:

2bfe1b0590a78457e1f1a6a90fb975f5878cb60064ccfe1d7db76ca0da52f0f3

By searching the above sha256sum in bugzilla, the gedit contributors can find again the tickets. We may be interested to do so when we work on a specific area of the code, to at least know the known problems and possible enhancements.

We do this mass-closing because bugzilla.gnome.org is being replaced by gitlab.gnome.org.