352340 - GetTextAtOffset doesn't work correctly for word boundaries

Status: RESOLVED FIXED

(Core :: Disability Access APIs, defect)

Description

[Aaron Leventhal]

1. Reference the above URL for the testcase.
2. Use word start or word end
3. Notice how the same word is returned each time

A new word should be returned each time.

Comment 1

[Mike Gao]

I think this is caused by the testcase.

Comment 2

[Mike Gao]

Attachment: Patch for jstest.js

I think this is not a bug. This patch for the test case works on my linux box.

Comment 3

[Aaron Leventhal]

The test case should show all the text. By feeding in the end offset each time back into getText, you should get the next chunk. That works when we do with BOUNDARY_LINE_START and BOUNDARY_LINE_END.

For example, if we take the following text:
abc def

We ask getTextAtOffset() using BOUNDARY_WORD_START at offset 0. We should get:
[0,4,"abc "]

Now ask getTextAtOffset() using BOUNDARY_WORD_START at offset 4. We should get
[4,7,"def"]

No?

Comment 4

[Mike Gao]

Accoding to 
http://developer.gnome.org/doc/API/2.0/atk/AtkText.html#atk-text-get-text-at-offset,
"If the boundary_type is ATK_TEXT_BOUNDARY_WORD_START the returned string is from the word start at or before the offset to the word start after the offset.

The returned string will contain the word at the offset if the offset is inside a word and will contain the word before the offset if the offset is not inside a word. "

In your example, should we get [0,4,"abc "] at offset 4?

Comment 5

[Aaron Leventhal]

(In reply to comment #4)
> In your example, should we get [0,4,"abc "] at offset 4?
No, do it like in comment 3.

Offset 4 is inside the word "def". Basically, any offset that contains a character from a word is inside the word. But thanks for making sure we clarify that, it could be confusing.

Comment 6

[Mike Gao]

Attachment: The patch.

Comment 7

[Mike Gao]

(In reply to comment #6)
> Created an attachment (id=240356) [edit]
> The patch.
> 

I have tested it on linux.

Comment 8

[Aaron Leventhal]

Comment on attachment 240356 [details] [diff] [review]
The patch.

I think we need to check if amount == eSelectWord.

Ginn, what do you think?

Also, should we also be doing anything when aType == eGetBefore?

You can probably put this new |if| block 2 lines up before |*aStartOffset = startOffset|, and just compare to endOffset instead of *aEndOffset.

Mike, with the next patch  please request r= from Ginn.

Comment 9

[Aaron Leventhal]

Also, please add a comment in the |if| block to say why it's necessary.

Comment 10

[Ginn Chen]

gaoming,

Please also fix the 2 NS_ASSERTIONs after.
I don't think they're correct.

BTW: We still have a bug, if I click the end of "abc" or "123" in the test case. 
Do you have the same problem?
Do we have a bug filed?

Comment 11

[Ginn Chen]

(In reply to comment #10)
> BTW: We still have a bug, if I click the end of "abc" or "123" in the test
> case. 
> Do you have the same problem?
> Do we have a bug filed?
> 

I just clicked outside the word.

Comment 12

[Mike Gao]

(In reply to comment #8)
> (From update of attachment 240356 [details] [diff] [review] [edit])
> I think we need to check if amount == eSelectWord.
> 

Yes. This would be safer.

> Ginn, what do you think?
> 
> Also, should we also be doing anything when aType == eGetBefore?
> 
we use "if (aType == eGetAt && amount == eSelectWord && aOffset == endOffset)" as the condition, so we need not do anything for eGetBefore, right?

> You can probably put this new |if| block 2 lines up before |*aStartOffset =
> startOffset|, and just compare to endOffset instead of *aEndOffset.
> 
> Mike, with the next patch  please request r= from Ginn.
> 

Comment 13

[Mike Gao]

(In reply to comment #11)
> (In reply to comment #10)
> > BTW: We still have a bug, if I click the end of "abc" or "123" in the test
> > case. 
> > Do you have the same problem?
> > Do we have a bug filed?
> > 
> 
> I just clicked outside the word.
> 

If you mean the Text: "[0,1] abc [1,6] 123 [6,10]", I get this when I click inside the text. Will you get any output if you click outside?

The odd Text: field hanppends for tag <span>. <br> is considered as one character and I don't know what [0,1] is.

Comment 14

[Mike Gao]

Attachment: patch draft v2

Comment 15

[Mike Gao]

Attachment: patch draft v3

Comment 16

[Ginn Chen]

(In reply to comment #13)

> If you mean the Text: "[0,1] abc [1,6] 123 [6,10]", I get this when I click
> inside the text. Will you get any output if you click outside?

Not in browser window.
In Error console or terminal.

************************************************************
* Call to xpconnect wrapped JSObject produced this error:  *
[Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIAccessibleText.getOffsetAtPoint]"  nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: http://www.mozilla.org/access/qa/jstest.js :: updateDisplay :: line 177"  data: no]
************************************************************

Never mind, it's not related to this bug.

Comment 17

[Ginn Chen]

checked in