[SuperEditor] Show software keyboard upon tap (Resolves #1816)

[angelosilvestre]

[SuperEditor] Show software keyboard upon tap. Resolves #1816

Steps to reproduce:

1. Place the selection at an arbitrary position
2. Close the software keyboard using the system button
3. Tap again on the same selected position

After that, the software keyboard isn't shown.

The reason is that we show the software keyboard when selection changes. Because the selection didn't change, the software keyboard isn't show.

This PR forwards SoftwareKeyboardController to the Android touch interactor so it can show the keyboard upon tap.

I couldn't reproduce this on iOS because I didn't find any system button to close the keyboard. We have an above-the-keyboard panel button to close the keyboard, but in reality we are closing the IME connection when tapping on it. I noticed that Flutter doesn't expose a method to close the software keyboard, so it's probably a good idea to file an issue for that.

Open questions:

• Should we remove the code that opens the keyboard when selection changes?
• Should we replicate the same implementation to iOS?

[matthew-carroll]

My initial thought is that if the Android gesture interactor only needs to be able to open the keyboard, then we probably shouldn't pass in a whole controller. In general, any API that you expose to an object will eventually be used by that object, even if not strictly necessary. So we should be careful when passing things around like that.

Is there any reason that we need to pass a whole controller instead of just a callback method?

Should we remove the code that opens the keyboard when selection changes?

I didn't follow the rationale there. Why do we want to remove it?

Should we replicate the same implementation to iOS?

Which implementation? Is there a behavior that's expected on iOS that we currently aren't honoring on iOS?

[angelosilvestre]

@matthew-carroll

Is there any reason that we need to pass a whole controller instead of just a callback method?

No particular reason. We can pass just a callback if needed.

Should we remove the code that opens the keyboard when selection changes?

I didn't follow the rationale there. Why do we want to remove it?

If we will always show the keyboard upon tap, showing the keyboard also when selection changes might be unnecessary.

Should we replicate the same implementation to iOS?

Which implementation? Is there a behavior that's expected on iOS that we currently aren't honoring on iOS?

I mean to show the keyboard upon tap

[matthew-carroll]

No particular reason. We can pass just a callback if needed.

Ok, let's do that.

If we will always show the keyboard upon tap, showing the keyboard also when selection changes might be unnecessary.

Do we have existing policies related to focus change, or programmatic placing of the caret, which would be impacted by that?

I mean to show the keyboard upon tap

Yeah, I suppose we should duplicate that change.

[angelosilvestre]

@matthew-carroll Updated the implementation.

If we will always show the keyboard upon tap, showing the keyboard also when selection changes might be unnecessary.

After checking again I think we shouldn't remove that, since it's configurable via policies.

[matthew-carroll]

Please change this to "opens software keyboard when tapping on caret"

Also, should there be a test for an expanded selection?

[angelosilvestre]

Updated.

[matthew-carroll]

LGTM