This is a theoretical issue, and was not complained in practice.
If we call the following InputConnection methods,
operation_a()
beginBatchEdit()
operation_b()
endBatchEdit()
operation_c()
Then selection update from operation_a() may be coalesced into the selection update at the end of endBatchEdit() because of the way it is implemented now.
ReplicaInputConnection did not have this problem, as it updated selection immediately after InputConnection method calls.
This is somewhat tricky to implement correctly. One idea is as follows:
1) ThreadedInputConnection keeps track of mNumNestedBatchEdits.
2) In the outermost beginBatchEdit(), ask render_widget to pause selection update until further notice.
3) When endBatchEdit() is called for the outermost batch (mNumNestedBatchEdits becomes 0), ask render_widget to resume selection update.
4) resetOnUiThread() should ask render_widget to resume selection update.
This way, endBatchEdit() can still return the correct boolean result.
I'm thinking of implementing this for M54 unless there is a real complaint.
Alex, what do you think about this?
Comment 1 by aelias@chromium.org
, Sep 3 2016