1200799 - Use InputPane.TryShow and InputPane.TryHide instead of invoking TabTip.exe directly

Status: RESOLVED WONTFIX

(Core :: Widget: Win32, defect)

Description

[Jared Wein [:jaws] (please needinfo? me)]

From an email thread about a way to reduce the need to specifically look for TabTip.exe and ShellExecute it,

> Are you able to use the InputPane APIs that we’ve converged for Windows 10?
> Instead of having to invoke Tabtip directly, you should be able to call
> InputPane.TryShow() and InputPane.TryHide() now to manipulate the touch
> keyboard.

> https://msdn.microsoft.com/en-us/library/windows.ui.viewmanagement.inputpane.tryshow.aspx?cs-save-lang=1&cs-lang=cpp#code-snippet-1

> In these cases we will use the OS heuristics used everywhere to prevent the
> actual showing and hiding in cases where there is no touch screen or there
> is a physical keyboard connected etc. If focus is moved to a non-editable
> field (that is, no TextPattern provider) though, the keyboard will still
> dismiss automatically. It’s not perfect but hopefully it will work better
> than invoking tabtip.exe directly.

Comment 1

[:Gijs (he/him)]

Based on my experiments with the Titlebar code ( https://reviewboard.mozilla.org/r/12599/diff/1/ ) I am not sure if the InputPane's GetForCurrentView would work from a non-winrt app.

I also don't know that we expose the TextPattern provider correctly right now.

Comment 2

[Jared Wein [:jaws] (please needinfo? me)]

I've gotten confirmation from someone at with Microsoft that these APIs are not available for non-WinRT apps and there are no immediate plans of adding them. They may come in a future release though.

For now we will have to improve the robustness of our current approach. I've filed bug 1209198 as the next step.