Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 313071

Summary: AccessibleTextExtendedListener.getText line/word offset problems
Product: [Eclipse Project] Platform Reporter: Carolyn MacLeod <carolynmacleod4>
Component: SWTAssignee: Carolyn MacLeod <carolynmacleod4>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: eclipse.felipe, Silenio_Quarti, skovatch
Version: 3.6Flags: Silenio_Quarti: review+
eclipse.felipe: review+
carolynmacleod4: review+
Target Milestone: 3.6 RC2   
Hardware: PC   
OS: All   
Whiteboard:
Attachments:
Description Flags
patch for GTK
none
patch for Winodws none

Description Carolyn MacLeod CLA 2010-05-17 02:08:34 EDT 
IAccessibleText::textAtOffset, textBeforeOffset, and textAfterOffset specify the following:

IA2_TEXT_BOUNDARY_WORD  The range provided matches the range observed when the application processes the Ctrl + left arrow and Ctrl + right arrow key sequences. Typically this is from the start of one word to the start of the next, but various applications are inconsistent in the handling of the end of a line.  

IA2_TEXT_BOUNDARY_LINE  Range is from start of one line to the start of another line. This often means that an end-of-line character will appear at the end of the range. However in the case of some applications an end-of-line character indicates the end of a paragraph and the lines composing the paragraph, other than the last line, do not contain an end of line character.  

We are reporting words and lines from start-to-end on Windows, instead of from start-to-start. We did it that way because the ATK API uses start-to-end on Linux.

We need to support both start-to-end on Linux and start-to-start on Windows.
Also need to double-check Mac implementation.
Comment 1 Carolyn MacLeod CLA 2010-05-17 02:09:56 EDT 
This is important for 3.6 RC2.

Note that we need to make changes on both Windows and GTK.
Comment 2 Carolyn MacLeod CLA 2010-05-17 13:51:12 EDT 
Scott, do you notice any discrepancies on the Mac in the area of offsets that are returned to VoiceOver when AccessibleTextExtendedListener.getText() is used to find a WORD or LINE?

SSQ and I are going to have to call AccessibleTextExtendedListener.getText() multiple times to get the exact offset data (and the string) that the platform wants.
Comment 3 Scott Kovatch CLA 2010-05-17 14:24:24 EDT 
(In reply to comment #2)
> Scott, do you notice any discrepancies on the Mac in the area of offsets that
> are returned to VoiceOver when AccessibleTextExtendedListener.getText() is used
> to find a WORD or LINE?

No, when I move from line to line or word to word I get the correct offsets. At the end of a line, however, StyledText treats the end of line as a distinct word, and I get a separate "new line" read back to me by VoiceOver. TextEdit doesn't do that, but I think I'm describing a navigation problem with StyledText as opposed to what you're looking at here.
Comment 4 Silenio Quarti CLA 2010-05-19 18:51:27 EDT 
Created attachment 169241 [details]
patch for GTK
Comment 5 Carolyn MacLeod CLA 2010-05-20 14:35:59 EDT 
Created attachment 169396 [details]
patch for Winodws
Comment 6 Carolyn MacLeod CLA 2010-05-20 14:38:37 EDT 
SSQ, please review the Windows patch in comment 5.
I will review the GTK patch in comment 4.
Felipe, please review both patches.
Comment 7 Felipe Heidrich CLA 2010-05-20 15:35:45 EDT 
Good,

In Car's patch, this should be changed (in all 3 methods).

	event.start = start;
	event.type = COM.IA2_TEXT_BOUNDARY_ALL;
	event.count = 0;

To:

	event.start = start;
	event.type = ACC.TEXT_BOUNDARY_ALL;
	event.count = 0;

(even though TEXT_BOUNDARY_ALL==IA2_TEXT_BOUNDARY_ALL==5)
Comment 8 Carolyn MacLeod CLA 2010-05-20 15:46:30 EDT 
Fixed > 20100520