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 456639 - [a11y] Text selection information not properly returned.
[a11y] Text selection information not properly returned.
Status: RESOLVED OBSOLETE
Product: vte
Classification: Core
Component: general
0.16.x
Other Linux
: Normal normal
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks: 456304
 
 
Reported: 2007-07-13 16:01 UTC by Rich Burridge
Modified: 2021-06-10 13:50 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Rich Burridge 2007-07-13 16:01:53 UTC
See also Orca bug #456304, which is blocked by this bug.

Steps to reproduce.

1/ Start Orca.
2/ Start gnome-terminal
3/ Select some text in gnome-terminal. I did this by vi'ing a
   text file and then click-drag-releasing the mouse over part of
   the text.
4/ Double click Numpad-+

The selected text is not spoken.

Numpad-+ in Orca is a "where am I" command. It tries to provide
the user with enough information on the component that currently
has focus, to help them know what's going on. Double-click Numpad-+
gives even more information. One of the extra things it should 
provide is what text is currently selected.

I debugged this a little further.

I started Orca and gnome-terminal. I used the mouse to select a word in the
terminal by double clicking it.

Setting debugging to LEVEL_OFF in where_am_I.py, and double
pressing Numpad-Enter gives the following output:

whereAmI:           
  label=                   
  name=Terminal            
  role=terminal                 
  mnemonics=['', '']        
  parent label=           
  parent name=                  
  parent role=filler           
  double-click=True
  orca-key=False
_getTextContents: caretOffset=1433, nSelections=1
_getTextSelections: getNSelections:  1
_getTextSelection: selection start=1433, end=1433
_getTextSelection: selected text=<>
newLine: <>
first text utterances=['', 'terminal', '']
SPEECH OUTPUT: ''
SPEECH OUTPUT: 'terminal'
SPEECH OUTPUT: ''
text utterances=['selected', '']
SPEECH OUTPUT: 'selected'

The interesting part here is that it correctly thinks there is
a selection, but when you call:

        for i in range(0, nSelections):
            [startOffset, endOffset] = textObj.getSelection(i)

in _getTextSelection() in where_am_I.py, it returns bogus results.
No matter what I select in the terminal window, I get back a start and
end offset of 1433.

This suggests to me, that the accessibility code in vte is not doing the
correct thing.
Comment 1 Joanmarie Diggs (IRC: joanie) 2010-09-14 08:19:42 UTC
Ping. This bug is over three years old and hasn't been triaged.

You do not need Orca to reproduce this problem. Instead, you can select some text from vte/gnome-terminal with the mouse. Then use Accerciser:

1. Locate the object of ROLE_TERMINAL in the tree of accessible objects on the left.

2. With that object selected, get into the iPython console and type:

   acc.queryText().getSelection(0)

The start and end offsets should NOT be the same. (Compare to the results obtained when performing a comparable test in Gedit.)

Also please note that at least some of AtkText selection is implemented:

  acc.queryText().getNSelections()

returns 1 when there is one text selection and 0 when there are none. So I believe all we're missing here are the correct offsets.
Comment 2 Behdad Esfahbod 2010-09-14 18:03:04 UTC
Joanmarie, how about you look into the code, debug it, and submit a patch?
Comment 3 Alejandro Leiva 2010-09-15 15:34:56 UTC
(In reply to comment #2)
> Joanmarie, how about you look into the code, debug it, and submit a patch?

Hi Behdad, I'm not Joanmarie, but I'm part of Orca Team. I'll get this this bug and I'll try  address the problem and submit a patch.

Cheers!
Comment 4 GNOME Infrastructure Team 2021-06-10 13:50:16 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/1419.