Closed Bug 908647 Opened 11 years ago Closed 7 years ago

Race condition issue between selection range and surrounding text changes

Categories

(Core :: DOM: Device Interfaces, defect)

defect
Not set
normal

Tracking

()

RESOLVED INCOMPLETE
tracking-b2g +

People

(Reporter: xyuan, Unassigned)

References

Details

(Whiteboard: [FT:System-Platform])

We need to reslove a race condition issue regarding selection range and surrounding text changes. It is addressed in the email discussion of Jonas Sicking(https://groups.google.com/d/msg/mozilla.dev.webapi/nZLOEvEL3Tk/w5whN5fBFxsJ)

...

* Race conditions between keyboard and app processes
Another issue that needs to be defined is what to do if the selection
changes between the point when we fire "onselectionchange", and the
keyboard app sends calls replaceSurroundingText or sendKey etc. I.e.
consider the following scenario:

1. The page focuses an <input> element
2. We bring up the keyboard and fire a oninputcontextchange event
3. The user clicks inside a misspelled word in the <input> element
4. We fire an onselectionchange event in the keyboard app
5. The keyboard app calls getText to investigate the text surrounding the cursor
6. We return a result to the keyboard app
7. The keyboard app realizes that the word is misspelled and displays
a suggested correction to the user.
8. The user clicks the suggestion and the keyboard app calls
replaceSurroundingText() to change the misspelled word.
9. Before the app receives the replaceSurroundingText command, the app
calls a function to move the cursor, either to move it to a new
inputcontext, or to move it inside the current inputcontext.
10. The app receives the replaceSurroundingText.

At this point, I think we need to detect that the text or cursor has
changed since the last time the keyboard app was notified. In this
case the replaceSurroundingText command should fail. I.e. no
modification should be done and we should make the Promise that was
returned report an error.

One way to do this is to in the app process and the keyboard process
keep a "generation-number". Any time the current inputcontext is
modified or any time cursor is moved we increase this
generation-number in the app process.

Whenever we send a onselectionchange, oninputcontextchange or
onsurroundingtextchange is sent from the app process to the keyboard
process we include the updated generation-number in the internal
notification from the app process to the keyboard process.

Whenever we actually fire the onselectionchange, oninputcontextchange
or onsurroundingtextchange events, we update the generation-number in
the keyboard process using the in the keyboard app.

Whenever we send a sendKey(), replaceSurroundingText() or other
modification from the keyboard process to the app process, we include
the keyboards current generation-number. When that notification is
processed by the app process we compare with the app process
generation-number. If the two are different we don't do the
modification and instead cause a failure. 

...
Can we modify the contextId to not just take context changes but also this into account? Wouldn't require changes in forms.js.
Yes, I think that's what we want.
feature-b2g: --- → 2.2?
Component: Gaia::Keyboard → DOM: Device Interfaces
Product: Firefox OS → Core
blocking-b2g: --- → backlog
Whiteboard: [FT:System-Platform]
feature-b2g: 2.2? → ---
tracking-b2g: --- → +
blocking-b2g: backlog → ---
More mass-incompleting of FxOS bugs in the Device Interfaces component.

Please update and let me know if any of these are still valid.
Status: NEW → RESOLVED
Closed: 7 years ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.