Prevent viewport resize when showing onscreen keyboard on Windows
Categories
(Core :: Widget: Win32, enhancement, P3)
Tracking
()
People
(Reporter: saschanaz, Unassigned)
References
Details
(Keywords: parity-chrome, Whiteboard: [win:touch])
Attachments
(2 files)
Chrome subscribes events from InputPane API and adjust the content window based on the size of the keyboard without resizing the whole window and the viewport size.
Firefox does not, and Windows resizes the window when showing the onscreen keyboard, thus affects the viewport size, triggering UI transition depending on CSS media rules of the pages.
See the behavior difference:
- Open https://codepen.io/aymak/pen/BaqqWZe
- Tap the address bar or any input box in the page (the latter currently somehow does not open the onscreen keyboard on Firefox but does on Chrome)
- See what happens when the onscreen keyboard opens
The way to prevent window resize is not well-documented, and it seems merely subscribing Showing event implicitly prevents that. (Edit: There needs to be more work to trigger proper scrolling, of course.) Try adding this in OSKInputPaneManager.cpp's GetInputPane.
auto completedCallback =
Callback<ABI::Windows::Foundation::ITypedEventHandler<
InputPane*, InputPaneVisibilityEventArgs*>>(
[](IInputPane* aPane,
IInputPaneVisibilityEventArgs* aArgs) -> HRESULT { return S_OK; });
EventRegistrationToken token;
inputPane->add_Showing(completedCallback.Get(), &token);
Reporter | ||
Comment 1•2 years ago
|
||
The Firefox behavior:
Updated•2 years ago
|
Comment 2•8 months ago
|
||
This was fixed as a side-effect of bug 1645571 — although as :saschanaz notes,
(Edit: There needs to be more work to trigger proper scrolling, of course.)
That will probably be covered by bug 1907766.
Reporter | ||
Comment 3•8 months ago
|
||
Can confirm, great work! (While it certainly causes bug 1907766 which kinda makes it worse for general use case e.g. here in Bugzilla)
Comment 4•8 months ago
|
||
... and bug 1645571 has been backed out, reintroducing this.
I'll avoid reopening this bug for now, though, since bug 1909951 has since been filed with a good summary of the current state of affairs. (It may be reopened later, depending on how we break this issue up.)
Description
•