Currently, the viewport drag button (the hand) is only shown when the remote session is larger than the local window. This causes the ui elements in the control bar to move and change positions when this button is shown and hidden. A better solution would probably be to always show the button but have it disabled instead when it currently is hidden.
The viewdrag button is the only button shown on the left hand side of the control bar on non-touch devices. Due to this I think the current behavior is good on non-touch devices. On touch devices however, we don't want the GUI to "jump around". This is especially irritating when opening/closing the on-screen keyboard on Android devices since this will resize the viewport. Thus we want this button to be disabled/enabled instead of shown/hidden on such platforms.
Fixed in commit 30402.
If panning state is selected and active while rotating the display which provokes a new resize, the button is disabled but the state is still active and mouse is not working as expected. Event the button is active state visually.
(In reply to comment #1) > The viewdrag button is the only button shown on the left hand side of the > control bar on non-touch devices. Due to this I think the current behavior is > good on non-touch devices. I have to correct myself here since non-touch devices never show the viewdrag button in ThinLinc's HTML5 client. The quoted statement is only true for noVNC. However since this became a non-question, the conclusion is still the same. (In reply to comment #3) > If panning state is selected and active while rotating the display which > provokes a new resize, the button is disabled but the state is still active and > mouse is not working as expected. Event the button is active state visually. Fixed in commit 30494. Keep Bug 5572 in mind while testing this.
The hand is now always shown. Tested with Firefox on Android.
(In reply to comment #3) > If panning state is selected and active while rotating the display which > provokes a new resize, the button is disabled but the state is still active and > mouse is not working as expected. Event the button is active state visually. I've also tested that this works as it should.
