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.

More mass-incompleting of FxOS bugs in the Device Interfaces component. Please update and let me know if any of these are still valid.