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)
Tracking
()
RESOLVED
FIXED
People
(Reporter: mick, Assigned: surkov)
References
(Blocks 1 open bug)
Details
(Keywords: access)
Attachments
(1 file, 1 obsolete file)
(deleted),
patch
|
Details | Diff | Splinter Review |
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.
Updated•16 years ago
|
Blocks: textattra11y
Assignee | ||
Comment 1•16 years ago
|
||
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
Assignee | ||
Comment 2•16 years ago
|
||
(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
Assignee | ||
Comment 3•16 years ago
|
||
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)
Assignee | ||
Updated•16 years ago
|
Attachment #334851 -
Flags: review?(marco.zehe)
Updated•16 years ago
|
Attachment #334851 -
Flags: superreview?(neil) → superreview+
Comment 4•16 years ago
|
||
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 5•16 years ago
|
||
Comment on attachment 334851 [details] [diff] [review]
patch
r=me for the test part. Thanks!
Attachment #334851 -
Flags: review?(marco.zehe) → review+
Assignee | ||
Comment 6•16 years ago
|
||
+ content mochitest
Attachment #334851 -
Attachment is obsolete: true
Assignee | ||
Updated•16 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 7•16 years ago
|
||
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.
Description
•