Issue 30980 - Function AccessibleText_getTextAtOffset returnes wrong values
Summary: Function AccessibleText_getTextAtOffset returnes wrong values
Status: CLOSED FIXED
Alias: None
Product: ui
Classification: Code
Component: AccessBridge (show other issues)
Version: OOo 1.0.3
Hardware: PC Linux, all
: P3 Trivial with 1 vote (vote)
Target Milestone: OOo 2.0.2
Assignee: eric.savary
QA Contact: issues@ui
URL:
Keywords: accessibility
: 46885 (view as issue list)
Depends on:
Blocks:
 
Reported: 2004-07-01 14:38 UTC by atelescu
Modified: 2006-02-09 09:29 UTC (History)
2 users (show)

See Also:
Issue Type: DEFECT
Latest Confirmation in: ---
Developer Difficulty: ---


Attachments
Proposed tester (2.19 KB, text/plain)
2004-08-12 15:20 UTC, atelescu
no flags Details
i30980.odt contains a dialog with a multiline edit field for testing purposes (10.24 KB, application/vnd.oasis.opendocument.text)
2006-01-05 16:23 UTC, thomas.benisch
no flags Details
i30980.odt corrected (10.24 KB, application/vnd.oasis.opendocument.text)
2006-01-09 13:58 UTC, thomas.benisch
no flags Details

Note You need to log in before you can comment on or make changes to this issue.
Description atelescu 2004-07-01 14:38:48 UTC
From StarOffice 7(OpenOffice)

-run setup application - './setup'
-<tab><tab><space> to show help
-<tab> to travel to multiline text

Move between lines and see the values for 'start_range ' and 'end_range'
calculated with this function.
 
Moving to a new paragraph => the entire paragraph is reported and not only the
current line.

Moving to a new line from the current paragraph => wrong values reported for
start_range and end_range of the current line.
Comment 1 atelescu 2004-07-01 14:46:51 UTC
Thig bug bloks:
http://bugzilla.gnome.org/show_bug.cgi?id=124107
Comment 2 ru 2004-08-05 15:27:08 UTC
Ralf -> Oliver: Can you please have a look.
Comment 3 ru 2004-08-05 15:27:34 UTC
.
Comment 4 dormenisan 2004-08-11 13:15:33 UTC
Same problem (incorrect ranges)for start word/end word.

In the multi-line paragraph, use Ctrl-<arrow> to read left/right by word.
Often the wrong things are read: you'll often get several characters in
addition to the word you just landed on, especially when crossing line breaks.

This is cause of bug:
http://bugzilla.gnome.org/show_bug.cgi?id=149599

 
Comment 5 atelescu 2004-08-11 14:10:13 UTC
Moving to a paragraph for the first time, the values for start / end of the
current line are equal to start / end of the paragraph.
This is cause of bug:
http://bugzilla.gnome.org/show_bug.cgi?id=149596 
Comment 6 atelescu 2004-08-11 14:15:49 UTC
The text ranges values for start / end line of a paragraph are wrong.

 This is the cause of bug:
http://bugzilla.gnome.org/show_bug.cgi?id=149597
Comment 7 atelescu 2004-08-11 14:25:04 UTC
Move between lines in the same paragraph.
When moving upward, what is reported is this case, is different to what is
reported moving downward.
 
This is the cause of bug:
http://bugzilla.gnome.org/show_bug.cgi?id=149598.


Comment 8 nospam4obr 2004-08-12 11:54:46 UTC
I can confirm that the multi line edit control does not handle text-type LINE
correctly: it always reports the full paragraph for the first line and also
fails to return WORDS in the other lines.

However the writer issue seems to be a completly different one - at least my
trace show correct values. Additionally the offsets are not passed to the
gnome-java-bridge anyway, since the Java Accessibility API did not have the
notion of text segments before Java 1.5 and I don't see support for those new
interfaces in the gnome-java-bridge yet.
Comment 9 atelescu 2004-08-12 15:17:29 UTC
I use a independent tester, to verify the ranges and the string returned by
function getTextAtOffset, both are wrong.
Comment 10 atelescu 2004-08-12 15:20:19 UTC
Created attachment 17104 [details]
Proposed tester
Comment 11 atelescu 2004-08-12 15:34:52 UTC
To use this tester:
  - download and rename this attachment as 'simple-at.c'
  - get at-spi from CVS HEAD
  - replace file at-spi/test/simple-at.c with this one
  [- delete files '*simple-at' and 'simple-at.o' to make sure that new files are
created after recompile ]
  - recompile
  - run '*simple-at'
Comment 12 dragan_s 2004-08-17 13:32:41 UTC
I hope this test output helps:

I wrote 1 line in Star Office :

line  = "word1 word2 word3"


****************************************************************************************************
I moved word-by-word in the first line and the test program generated the output
you can see below:*

NOTE: The line is exactly written like above (with the spaces).

At first the caret is on the firs positioin in the line.

Notice that moving word-by-word , the text from  _WORD START_ is composed from
the first word and the second, 
which is WRONG because _WORD START_ should be ONLY the firs word.

Taking the first case from the output below :
    
WORD START: 	text:|word1word2|   *****BAD******
WORD START: 	text:|word1|	    *****GOOD*******


****************************************************************************************************
0: 8072a30p object:text-caret-moved for Paragraph 1(Paragraph: word1 word2 word3
) role text with details 0 10
TEXT:
	BOUNDARY:
		WORD START: 	range -1-9	text:|word1word2|
		LINE START: 	range 0-17	text:|word1 word2 word3|
1: 8072a30p object:text-caret-moved for Paragraph 1(Paragraph: word1 word2 word3
) role text with details 6 0
TEXT:
	BOUNDARY:
		WORD START: 	range -1-9	text:|word2word3|
		LINE START: 	range 0-17	text:|word1 word2 word3|
2: 8072a30p object:text-caret-moved for Paragraph 1(Paragraph: word1 word2 word3
) role text with details 12 6
TEXT:
	BOUNDARY:
		WORD START: 	range 12-17	text:|word3|
		LINE START: 	range 0-17	text:|word1 word2 word3|
3: 8072a30p object:text-caret-moved for Paragraph 1(Paragraph: word1 word2 word3
) role text with details 17 12
TEXT:
	BOUNDARY:
		WORD START: 	range 10-16	text:|word3 |
		LINE START: 	range 0-17	text:|word1 word2 word3|
Comment 13 nospam4obr 2004-08-18 06:43:41 UTC
I have created a seperate issue for the bug with writer / word iteration: #i33129#
Comment 14 thomas.benisch 2004-08-23 11:49:27 UTC
set target to OOo 2.0
Comment 15 christof.pintaske 2004-10-29 15:52:24 UTC
retarget to later due to missing ressources
Comment 16 eric.savary 2005-04-07 13:49:20 UTC
*** Issue 46885 has been marked as a duplicate of this issue. ***
Comment 17 billhaneman 2005-05-24 15:36:23 UTC
PLEASE TAKE THIS OFF the 'later' milestone!  This is a very serious defect for
accessibility, one of the worst against OOo in my opinion.
Comment 18 thomas.benisch 2005-05-25 09:49:02 UTC
set target milestone to OOo 2.0.2
Comment 19 mdxonefour 2005-09-29 11:04:12 UTC
re-targeted to OOo 3.0
Comment 20 mdxonefour 2005-09-30 07:28:42 UTC
re-targeting back to OOo 2.0.2, re-targeting to OOo 3.0 was done by error
Comment 21 thomas.benisch 2006-01-05 16:23:13 UTC
Created attachment 32931 [details]
i30980.odt contains a dialog with a multiline edit field for testing purposes
Comment 22 thomas.benisch 2006-01-05 16:27:33 UTC
fixed in CWS tbe27
Comment 23 thomas.benisch 2006-01-09 13:58:53 UTC
Created attachment 33055 [details]
i30980.odt corrected
Comment 24 thomas.benisch 2006-01-12 13:23:29 UTC
TBE->ES: Please verify on CWS tbe27.

re-open issue and reassign to es@openoffice.org
Comment 25 thomas.benisch 2006-01-12 13:23:35 UTC
reassign to es@openoffice.org
Comment 26 thomas.benisch 2006-01-12 13:23:42 UTC
reset resolution to FIXED
Comment 27 eric.savary 2006-01-17 16:16:23 UTC
Verified in CWS tbe27.
Comment 28 eric.savary 2006-02-09 09:29:02 UTC
Ok in src680m156