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.
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.
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.