Bug 6059 - Web Access scrolls to top on iOS with virtual keyboard open
Summary: Web Access scrolls to top on iOS with virtual keyboard open
Alias: None
Product: ThinLinc
Classification: Unclassified
Component: Web Access (show other bugs)
Version: 1.3.1
Hardware: PC Unknown
: P2 Normal
Target Milestone: 4.14.0
Assignee: Linn
Keywords: focus_focus
Depends on: 7792
  Show dependency treegraph
Reported: 2016-10-14 13:58 CEST by Pierre Ossman
Modified: 2021-11-22 12:24 CET (History)
2 users (show)

See Also:
Acceptance Criteria:


Description Pierre Ossman cendio 2016-10-14 13:58:31 CEST
The virtual keyboard on iOS does not resize the browser. Instead you are allowed to scroll your page to see the part obscured by the keyboard. In the HTML client you can do this by dragging on the toolbar.

However some actions causes it to bounce back to the top scroll position. E.g. pushing one of the extra keys buttons. This is probably a side effect of us trying to restore focus to the keyboard, and the keyboard input element is located at the top of the page.
Comment 1 Pierre Ossman cendio 2016-10-18 11:24:41 CEST
Perhaps we should move the input field to where the user clicked last. That should have a high likelihood of being where the input field is.
Comment 2 Samuel Mannehed cendio 2016-10-18 14:06:48 CEST
It is likely that this happens on Windows Mobile as well, since the keyboard seems to be working similarly to the one on iOS.
Comment 3 Pierre Ossman cendio 2021-11-16 17:06:14 CET
Possibly fixed via this upstream issue:

Comment 4 Samuel Mannehed cendio 2021-11-17 13:36:08 CET
This might be fixed in the vendordrop, needs testing.
Comment 6 Linn cendio 2021-11-22 10:19:29 CET
This problem seems to have been solved along the way, and I have been unable to reproduce it. 

Tested with jenkins build 2350 on Safari 15, and none of our extra keys buttons causes a bounce back. However, pressing the ctrl-alt-del button causes the keyboard to close, which may or may not be intended.

As a side note, this issue might have been solved in this noVNC commit [1], which was included in ThinLinc 4.11. I also tried reproducing the issue with 4.10.1 but was unable to see it.

[1]: https://github.com/novnc/noVNC/commit/a5aa8e12822a0b83f2521ed04911a03f3f33c192

Note You need to log in before you can comment on or make changes to this bug.