Closed Bug 1139887 Opened 5 years ago Closed 5 years ago

IPC Proxy for caretOffset

Categories

(Core :: Disability Access APIs, defect)

36 Branch
x86_64
Linux
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla39
Tracking Status
firefox39 --- fixed

People

(Reporter: smaug, Assigned: smaug)

Details

Attachments

(2 files)

Attached patch v1Splinter Review
No description provided.
Attachment #8573230 - Flags: review?(tbsaunde+mozbugs)
Assignee: nobody → bugs
On IRC you were worried about 'sync SetCaretOffset'. Any particular reason why that would be
more worrisome than other sync stuff?
Flags: needinfo?(tbsaunde+mozbugs)
(In reply to Olli Pettay [:smaug] (no new review requests before March 8, please) from comment #1)
> On IRC you were worried about 'sync SetCaretOffset'. Any particular reason
> why that would be
> more worrisome than other sync stuff?

Well, the rest of it is conceptually read only and this is not.  In an ideal world it would trigger an event being immediately dispatched, and and so calling into code of the a11y consumers.  However that's not currently the case, and I'm not sure it ever will be.

So currently get and set CaretOffset are non racy, but caret move events are racy  in that there exists a period of time in which the caret has moved but the event has not yet been fired.  If we use sync SetCaretOffset then I think we keep that situation.  Ohter mutating a11y things are mixed DoAction() is the same as async, and TakeFocus() is sync.  I was hoping we wouldn't need to use sync ipc for any mutators, but I guess this is fine for now :(
Flags: needinfo?(tbsaunde+mozbugs)
Attachment #8573230 - Flags: review?(tbsaunde+mozbugs) → review+
Attached patch v2Splinter Review
Include -inl.h
https://hg.mozilla.org/mozilla-central/rev/2d66bec2f5e1
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla39
You need to log in before you can comment on or make changes to this bug.