New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing scroll bars on OS X #598
Comments
I was using vnc_auto.html instead of vnc.html. I didn't see the autoconnect argument in vnc.html until just now, so I was using vnc_auto to automate the connection. Yes, the drag viewport is working as expected in Chrome for android, and probably as expected everywhere else. I'll check on OSX as soon as I can get my hands on a mac. Two thought on the move/drag viewport mode, would it be possible for a tap to still register as a click, and is would it be possible to enable by default when the local screen is smaller than the remote? I'm sure I can hack in the start by default function, but that's not very useful when a user can't click without turning off move/drag mode. |
I just implemented the tap to click in drag mode, it was easier than I expected. Would you be interested in pulling this new feature? For my use, I intend to enable drag mode by default on a touch device when the local display is smaller than remote. Combined with tap to click, I think it is a more intuitive experience for a normal user. |
Yes, it sounds interesting, I would be happy to look on a PR! In drag mode, how do you distinguish between clicks and drags? Simply triggering drag when the position changes? I'm closing this issue, please open a new issue/PR for the click-in-drag-mode feature. |
No need to open a new issue. |
@DirectXMan12 @samhed So it looks like this actually is an issue on Safari on newer osx machines. The problem is that the browser is hiding the scroll bars by default. Even when the scroll bars are present, the canvas is capturing the mouse events instead of the local browser. A workaround is to go into the OS's settings and disable autohide scrollbars. Seems to be present in El Capitan and Yosemity. I actually think this should be considered a safari bug, as the scroll bars should capture the mouse events when the mouse is over them. Up to you as to whether I open a new bug, or continue using this one. |
So this is when you are not using the "clip" setting, correct? I'll see if I can reproduce this on Monday. |
I can indeed reproduce this. I agree that this behavior in Safari is shitty and I would love if the browsers could make our lives easier by standardizing things like this. To submit a bug to Apple you need to have a Apple developer account, which I personally don't have. The only other option I am able to find is to submit feedback.. Which they say they don't care to respond to. I have a feeling the best way forward here is to add just another Safari workaround where we force clipping mode. |
Fixed in f620259 |
Perhaps I was a bit hasty here. There might be a way to use css to force the scrollbars to not automatically hide on Safari. I'll look further into this tomorrow. |
Worth looking into. Part of the issue, though, is that even when the scroll bars are visible, the browser is drawing them over the canvas, and not intercepting mouse clicks correctly. What if we limited the size of the canvas, reserving a few pixels on the right and bottom edge, so that the scroll bars worked correctly when visible. Another possibility: we could get fancy with interpreting scroll wheel input. Scroll wheel events could be applied to the local browser, panning around on the canvas, unless the canvas is already scrolled all the way to that edge, in which case the scroll wheel event would pass to the remote machine. That could, in fact, be useful for any desktop platform. |
Unless my memory is failing me, I was able to use the visible scrollbars just fine by drag-and-dropping on the edges. I'll double check tomorrow. My gut says that would feel rather annoying :) but it's difficult to tell without trying it out. Feel free to create a prototype for that. |
I don't have a mac to work on, making this slightly harder to troubleshoot. The two I tested on, though, was was failing to move the scroll bars when clicking and dragging them while they were drawn over the canvas. Clicking and dragging the scrollbar in a location where it was drawn over the status bar worked. That might not be true on every machine, hard to say. Regarding local vs remote scrolling: I've observed that new users, particularly those used to macs, see the local scroll bars and instinctively try to two finger scroll on their touch pads, and get a moment of confusion when that doesn't work. I'll try to get some time to mock up the fancy scrolling and see if it works and is a good experience. |
Anyone come up a solution for this bug on iOS device? Currently I am using the iPad accessing the VNC, but the scrolling doesn't work at all. |
Scrolling is disabled on touch devices, don't you get the panning "hand"? |
Yes, I did. But the panning "hand" doesn't help in scrolling(neither Safari or Chrome), only current showing part can be dragged. BTW, everything works well on my laptop. |
Is that clicking the scrolling bar is the only way to simulate the scrolling? |
I'm sorry, what? To pan on touch devices, you are supposed to drag across the screen while the panning button is highlighted. |
The problem is that currently I cannot scroll the content vertically even the panning button is highlighted. |
Scrollbars are now allowed on Safari as of b18ef81 |
And panning works now as well. |
There is a usability issue on mobile and osX platforms, namely the missing scroll bars. On mobile particularly, all touch events are passed through to the host computer, so if the client cannot display the entire screen, there is no way to scroll what portion of the display is shown.
On OSx, the scroll bars are hidden by default, also making it nearly impossible to scroll.
Perhaps on detecting a mobile client, a "click and drag" type event should scroll/pan the visible region?
The text was updated successfully, but these errors were encountered: