Closed Bug 451376 Opened 16 years ago Closed 16 years ago

IAccessibleText::attributes provides incorrect info after a mis-spelled word

Categories

(Core :: Disability Access APIs, defect)

x86
Windows Vista
defect
Not set
major

Tracking

()

RESOLVED FIXED

People

(Reporter: mick, Assigned: surkov)

References

(Blocks 1 open bug)

Details

(Keywords: access)

Attachments

(1 file, 1 obsolete file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a2pre) Gecko/20080819034536 Minefield/3.1a2pre
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a2pre) Gecko/20080819034536 Minefield/3.1a2pre ID:20080819034536

IAccessibleText::attributes returns the attribute run representing a mis-spelled word, if you give it an offset which is the offset after that attribute run. i.e. its the endOffset of the attribute run.

Reproducible: Always

Steps to Reproduce:
1. In a new thunderbird message, type "This iss a test".
2. call IAccessibleText::attributes for that node of text giving it an offset of 0, to get the "This " attribute run.
3. Give it an offset of 5, to get the "iss " attribute run [the mis-spelling] 
4. Give it an offset of 8, the start of the final attribute run [after the mis-spelling].
5. Give it an offset of 9.
Actual Results:  
*Giving 0 gives back startOffset: 0, endOffset: 5, and the appropriate attributes.
*Giving 5 gives back startOffset: 5, endOffset:8, and the attributes for that run.
*Giving 8 gives back StartOffset: 5, endOffset: 8, and attributes for that run.
*Giving 9 gives back startOffset: 8, endOffset: 15, and the attributes for that run.

Expected Results:  
*Giving 8 should give back startOffset: 8, endOffset: 15.

It seems that this bug is only related to the attribute runs of mis-spellings. The tests I have done seem to show that other attribute runs for bold, italic etc, do not cause this problem. 
This issue is very important as it can cause any AT using IAccessibleText::attributes to possibly go in to an infinite loop as the relationship between the given offset, and the resulting start and end offsets is not correct.
Keywords: access
Blocks: 345759
Version: unspecified → Trunk
Blocks: textattra11y
What kind of intervals should we use [a, b) or [a, b]? Iirc, we talked with Marco and we bend to use closed intervals like [a,b]. But what do you thing?
Assignee: nobody → surkov.alexander
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #1)
> What kind of intervals should we use [a, b) or [a, b]? Iirc, we talked with
> Marco and we bend to use closed intervals like [a,b]. But what do you thing?
> 

by the way, ranges don't use closed intervals http://www.w3.org/TR/2000/REC-DOM-Level-2-Traversal-Range-20001113/ranges.html, possibly we should follow it too
Attached patch patch (obsolete) — Splinter Review
nsIDOMNSRange::ComparePoint should return 1 (the point is after range) if the given node and offset are equal to end node and end offset of the range because end bound isn't included into range
Attachment #334851 - Flags: superreview?(neil)
Attachment #334851 - Flags: review?(Olli.Pettay)
Attachment #334851 - Flags: review?(marco.zehe)
Attachment #334851 - Flags: superreview?(neil) → superreview+
Comment on attachment 334851 [details] [diff] [review]
patch

1.8 seems to have the same bug. Please write some mochitest to test range.comparePoint() and maybe also .isPointInRange(). If you do that, r=me :)
Attachment #334851 - Flags: review?(Olli.Pettay) → review+
Comment on attachment 334851 [details] [diff] [review]
patch

r=me for the test part. Thanks!
Attachment #334851 - Flags: review?(marco.zehe) → review+
Attached patch patch2Splinter Review
+ content mochitest
Attachment #334851 - Attachment is obsolete: true
Status: NEW → ASSIGNED
http://hg.mozilla.org/mozilla-central/index.cgi/rev/3b707bbddf47
Status: ASSIGNED → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: