Why is there a TSFTextStore per input type?

[BoCupp-Microsoft]

Can't the TSFTextStore change its type? I believe TSF1 supports that, doesn't it?

What happens if a focused editable element changes from input type="text" to type="email"? Do you swap the associated text store?

[siliu1]

Yes. TSF1 supports switching types in TSFTextStore. We also need to switch ITfContext if the type of edit control has been changed. For example, if a focused input control changes from type="text" to type="password", we need to call into Windows Input Services about the input type change, we also need to switch to a disalbed ITfContext assotiates iwth TSFTextStore so that we don't report user password.

In current design, if input type changes from "text" to "password", we swap the assotiated text store which already has a disabled ITfContext.

[yukawa]

Hi there,

One of the initial implementers of TSFTextStore here.

For as long as I can remember, there is no strong reason behind the current design, which was introduced by me at crrev.com/11871033 to add InputScope support.

The main motivation of not reusing the same TSFTextStore instance there was just to avoid updating InputScope in a dynamic manner.

• If we create multiple instances of ITfDocumentMgr so that each input type can be associated with a dedicated TSFTextStore, then "input type change" can be seen as "focus change" from the IME.
• If we reuse the same instance of TSFTextStore, then we need to dynamically update InputScope every time the corresponding input type is updated. I guess this can be done by calling ITextStoreACPSink::OnAttrsChange.

When I implemented it, I was not sure whether most of existing IMEs could handle the later behavior correctly or not. So I just went with the former approach.

Reading my code again, TSFBridgeImpl::tsf_document_map_ doesn't seem to be mandatory for the former design though. I guess we can remove it by always creating a new pair of ITfDocumentMgr and TSFTextStore for each input type change.

Hope this helps.