Cannot click "scale" feature inside noVNC


I really REALLY need to be able to do this by Friday. I need suggestions, recommendations, and workarounds if need be…

thanks in advance…


There appears to be an “initial scale” inside the vnc.html file. I’ll tweak it there and let you know… :slight_smile:


Pro-tip, when using multiple monitors, check your other monitors for High Fidelity dropdown options from WebEntities.


Actually, yes @Caitlyn I do like turtles.




Hey James, would you mind going into a bit more detail about how to accomplish this? I have admin rights on my router and my machines are in-house. When doing an ipchicken or DYNDNS I am given the IP of the Gateway. Can you help me out?

cc: @b

Thanks in advance.


Do you know how to forward ports on your router? You’ll need to forward the VNC port to the local IP of the machine that is running VNC. That way those that hit you at the public IP (that you’ll set on the web entity) will be able to reach your VNC server.


I recall doing port forwarding back in the days when Starcraft 1 didn’t have the best networking built-in to :smiley:

Ok, so I’ll need to forward the port ((in my usecase it is 5900)) to the local IP addy of the machine that has websockify “broadcasting” it. I will definitely give that a shot right now.



ErrorCode: 10061.
No connection could be made because the target machine actively refused it. [my_public_gateway_ip]:8787

The only thing different is port forwarding on the Router, and I changed the Source URL in the WebEntity.

I did not change anything in the settings of the websockify powershell execution.

But perhaps I’m supposed to? Shouldn’t the websockify be modified to reflect the public IP?
Here is the port forwarding page.


You mabye hit a common problem. Failing or not available Router loopback ?
A common problem you did see with opensim and some hardware.

Mabye good to check if yourt router is having loopback functionality. Or you mabye need to activate it.


As @Richardus.Raymaker points out, you may not be able to see the entity from inside your network if it doesn’t hairpin a request for PUBLIC_IP:PORT to LOCAL_IP:PORT based on the port forward from inside your network.

One way to work around this would be to add an entry in your hosts file for the public IP and point it to your machine.



I’ll remap via hosts file.



Not marking this as solved because the root issue is that QML Windows using form elements act very bizarre when using Interface and a multiple monitor setup. Not while running Interface in multi-monitor, just having Interface as a window and using multiple monitors is causing the problem.


Can you expand on this or provide a minimal example? I use multiple monitors so I can look into it and see if it’s something that can be solved easily.


No problem.

All of these steps will assume you are running HF Interface in a window. That windows size ((unless spot on 1920x1080, is likely un-important))

  1. Follow the VNC tutorial as explained on the blog. Will work with LAN or localhost.

  2. Jot down the resolution of the monitor your using to “serve” the VNC stuff. In my case the aspect ratio was 16:10… the standard WebEntity is 16:9 and sizes according to 1.6m X 0.9m in HiFi.

  3. After you have the address of the VNC inside the WebEntity, you should expect to see the “landing page” vnc.html It is grey and you will be presented with login form in the top right.

  4. Resize the WebEntity before you login to the VNC page. You’ll note that the VNC canvas does not resize. “ok, a problem in the CSS, right?” wrong. Inside base.css it is explicitly stated that changing the values will do nothing. It instead tells you to use the Scale feature of the .html page.

  5. Ok, so you decide to try to click on the gear that will enable you to select local scaling but you can’t get to it… Try using Tab or tabindex… no dice.

…whoa… what was that… over on my desktop on the right-flank monitor? well I’ll be damned… it’s the dropdown options… how in the HELL did they get WAY over there???

I hope these steps are enough to get you moving on it. I’m extremely puzzled by the behavior and have noted it happens on other HF_owned QML windows.

Thanks in advance for anything you uncover from this.


Ah, OK. This is currently a limitation with the WebViews. The problem is that in order to support VR properly, all our UI needs to be QML based, right? Except this doesn’t quite work perfectly because some QML elements always resort to using a native control type, in particular menus and combo boxes (both of which will attempt to use the native pop-up menu control to render). I actually have an open bug against Qt for this.

For our own UI elements we’ve managed to work around this by writing custom combo box and menu controls that don’t use the native controls. Unfortunately, the Qt WebEngineView that contains any HTML has it’s own built in functionality to handle combo-boxes requested by the Chromium webengine… and that still ends up using the native control. This means that you never see combo boxes presented by an HTML page inside a VR HMD… and what’s more, the calculation of where to place the ‘native’ combobox on the actual desktop seems to be completely screwed by the disconnect between the offscreen QML window we use to render the page and the actual desktop window in which we display all the content. Multi-monitor systems probable exacerbate the situation. I suspect that the mechanism is trying to place the menu in the same relative position on the system desktop as the web view is on the offscreen ‘desktop’ but the offscreen desktop is always going to be exact same size as the Hifi window.

Unfortunately, fixing this would require a custom build of Qt that completely replaces the functionality of this class. It might be possible to find a way to tell Qt to override where it gets the definitions for these types however. I’ll look into it.