caretOffset for textarea should be -1 when textarea doesn't have a focus

RESOLVED FIXED in mozilla13

Status

()

Core
Disability Access APIs
RESOLVED FIXED
5 years ago
5 years ago

People

(Reporter: surkov, Assigned: surkov)

Tracking

(Blocks: 1 bug, {access})

unspecified
mozilla13
access
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Assignee)

Description

5 years ago
when document is focused but textarea is not then caretOffset on textarea returns the focus position of selection.
(Assignee)

Comment 1

5 years ago
Created attachment 595669 [details] [diff] [review]
patch

new portions of ifs unfortunately
Assignee: nobody → surkov.alexander
Status: NEW → ASSIGNED
Attachment #595669 - Flags: review?(trev.saunders)
(Assignee)

Comment 2

5 years ago
note, the patch enables tests disabled in bug 510128
(Assignee)

Comment 3

5 years ago
(In reply to alexander :surkov from comment #2)
> note, the patch enables tests disabled in bug 510128

and I think this bug is a fix for bug 510128

Comment 4

5 years ago
Comment on attachment 595669 [details] [diff] [review]
patch

Nice to get rid of that todo!
(Assignee)

Comment 5

5 years ago
some details:
Since elements like input or textarea has own selection controller then selection we get is different from documents one. Since selection is turned into caret position then we can get result different from -1 for these controls if document is focused (see eContainedByFocus check in nsHyperTextAccessible::GetCaretOffset).
Comment on attachment 595669 [details] [diff] [review]
patch

its kind of weird but I think this makes sense.  We should look at ways to make the check if we're focusable faster.
Attachment #595669 - Flags: review?(trev.saunders) → review+
https://hg.mozilla.org/mozilla-central/rev/c646a6e4dd2e
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla13
You need to log in before you can comment on or make changes to this bug.