Closed
Bug 672717
Opened 13 years ago
Closed 11 years ago
Broken caret when moving into/out of embedded objects with right arrow
Categories
(Core :: Disability Access APIs, defect)
Tracking
()
RESOLVED
FIXED
mozilla27
People
(Reporter: Jamie, Assigned: surkov)
References
(Blocks 1 open bug)
Details
Attachments
(1 file)
|
(deleted),
patch
|
tbsaunde
:
review+
|
Details | Diff | Splinter Review |
This bug possibly covers several separate issues, but they're difficult to describe separately and I'm not sure how to split them.
Str:
1. Retrieve the document, paragraph and link accessibles created for the following HTML:
<body contentEditable="true">
<p>a<a href="#">b</a>c</p>
2. Move the caret to "a".
For these steps, watch for caret movement events and check the caret offset for the document, paragraph and link accessibles.
3. Press right arrow (moving to "b").
Expected: Caret event on link, document caret offset 0 (paragraph object), paragraph caret offset 1 (link object), link caret offset 0 ("b").
Actual: Caret event on paragraph, document caret offset 1 (end of document), paragraph caret offset 1 (link object; correct), link caret offset -1 (does not have caret).
4. Press right arrow (moving to "c").
Expected: Caret event on paragraph, document caret offset 0 (paragraph object), paragraph caret offset 2 ("c"), link caret offset -1 (does not have caret).
Actual: Caret event on link, document caret offset 1 (end of document), paragraph caret offset 2 ("c"; correct), link caret offset 1 (end of link).
Left arrow seems to behave correctly.
This breaks caret tracking with NVDA's support for Mozilla rich text editing (currently in development).
|
Assignee | |
Comment 1•11 years ago
|
||
(In reply to James Teh [:Jamie] from comment #0)
> For these steps, watch for caret movement events and check the caret offset
> for the document, paragraph and link accessibles.
> 3. Press right arrow (moving to "b").
> Expected: Caret event on link, document caret offset 0 (paragraph object),
> paragraph caret offset 1 (link object), link caret offset 0 ("b").
> Actual: Caret event on paragraph, document caret offset 1 (end of document),
> paragraph caret offset 1 (link object; correct), link caret offset -1 (does
> not have caret).
in this case the caret is before the link (opposite to inside the link, same hypertext offset) that's why you get an event for paragraph. A document offset problem should be covered by question "should we use offset before an embedded character or after it when caret is inside embedded character". Should we use the same offsets when caret is right after embedded character and when caret is at the end of text of embeded character?
|
Reporter | |
Comment 2•11 years ago
|
||
(In reply to alexander :surkov from comment #1)
> > 3. Press right arrow (moving to "b").
> in this case the caret is before the link (opposite to inside the link, same
> hypertext offset) that's why you get an event for paragraph.
Ah. I understand. To give you some background, Windows screen readers always read the character immediately following the caret, which is why this is confusing; I expected the caret offset to always reflect the offset for the character immediately following the caret. Also, this means the caret offset for the link is never 0 and goes to 1 when you next press right arrow, which seems odd. That said, typing a character inserts it before the link, not inside. Tricky.
> A document
> offset problem should be covered by question "should we use offset before an
> embedded character or after it when caret is inside embedded character".
When the caret is inside an embedded object, I think the caret offset should always be that of the embedded character. I just checked and the IA2 spec agrees.
> Should we use the same offsets when caret is right after embedded character
> and when caret is at the end of text of embeded character?
Again, I expected the caret offset to be for the character immediately following the caret. However, typing a character inserts it into the link, not the paragraph, so this is arguable.
I also didn't realise the insertion point is different depending on whether you use left or right arrow.
Thanks for explaining this. I hadn't considered these issues and now I'm at a bit of a loss as to what is correct. :)
I think the one clear issue that needs to be fixed is that the caret offset should always be the embedded character if the caret is inside it.
|
|
Reporter | |
Comment 3•11 years ago
|
||
So, let's simplify.
(In reply to James Teh [:Jamie] from comment #2)
> I think the one clear issue that needs to be fixed is that the caret offset
> should always be the embedded character if the caret is inside it.
I'm okay with the rest being left alone except for this one issue.
|
|
Assignee | |
Comment 4•11 years ago
|
||
(I'm pretty sure Jamie said the bug continues to hit AT, add bug q3 dependency for now)
Blocks: 2013q3a11y
|
|
Assignee | |
Comment 5•11 years ago
|
||
try server build will be here: http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/surkov.alexander@gmail.com-e3e7c0ccfbf8
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #804110 -
Flags: review?(trev.saunders)
Attachment #804110 -
Flags: feedback?(jamie)
|
||
Comment 6•11 years ago
|
||
Comment on attachment 804110 [details] [diff] [review]
patch
>+ var checkList = aList[i][1];
>+ var textAcc = checkList[0][0];
>+ var textOffset = checkList[0][1];
>+ var textList = checkList.shift();
do you need the variable for something? I gues the .shift() weirdness is because checker takes first pair? maybe it would clearer for the data structure to be (point * point * point list) list
>+ var traversalList = [
I think this would be clearer written like
[
{
point: [ point, idx ],
testPoints: [
[ node1, idx1 ]
]
}
]
Attachment #804110 -
Flags: review?(trev.saunders) → review+
|
|
Assignee | |
Comment 7•11 years ago
|
||
Does it look fine?
{ // before 'a'
DOMPoint: [ getNode("p2", p2Doc).firstChild, 0 ],
point: [ getNode("p2", p2Doc), 0 ],
pointList: [ p2Doc, 0 ]
}
|
|
||
Comment 8•11 years ago
|
||
sure
|
|
Assignee | |
Comment 9•11 years ago
|
||
landed hg.mozilla.org/integration/mozilla-inbound/rev/5d2275143608
Marco, Jamie, please give it a try when nightly is out. That may deliver some regressions.
|
|
Assignee | |
Updated•11 years ago
|
Attachment #804110 -
Flags: feedback?(jamie)
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla27
You need to log in
before you can comment on or make changes to this bug.
Description
•