You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When clicking the Connect to VM button, the browser blocks the popup window. Tested in Google Chrome.
This is because the kimchi Javascript (1) does AJAX transactions, and when they are done (2) attempt to open a new window, but this is no longer in the context of the user clicking on something, and is therefore blocked by standard popup blockers.
I hacked the Javascript code so that kimchi (1) does "var x = window.open();", then (2) fires off AJAX requests, and when those return (3) sets the new window's location using "x.location = blah;". This works.
Unfortunately it doesn't work on iPads. So I tried again, this time just reverting the logic so that window.open() happens first, and the AJAX requests to start QEMU-VNC happens second.
I half expected this to cause a race condition where the websockets connection is dropped by websockify, because the backend QEMU-VNC port either has not been assigned yet, or has been assigned but is returning TCP RST because it's not running yet.
However, I've done quite a bit of testing, and have not run into the race condition even once, so it seems like a very good solution.
(Not sure why the race condition does not occur. Maybe websockify is able to wait until the port is available before connecting or something?)
Anyway, works great. Patch available if any interest.
The text was updated successfully, but these errors were encountered:
Thinking about it a bit more, I think that when clicking "connect to VM", nothing else but opening the new window should be performed.
The URL pointed to in the new window should contain the AJAX code to call the server and request the QEMU-VNC port be opened and whatever else needs to be done in addition to showing the novnc GUI.
When clicking the Connect to VM button, the browser blocks the popup window. Tested in Google Chrome.
This is because the kimchi Javascript (1) does AJAX transactions, and when they are done (2) attempt to open a new window, but this is no longer in the context of the user clicking on something, and is therefore blocked by standard popup blockers.
I hacked the Javascript code so that kimchi (1) does "var x = window.open();", then (2) fires off AJAX requests, and when those return (3) sets the new window's location using "x.location = blah;". This works.
Unfortunately it doesn't work on iPads. So I tried again, this time just reverting the logic so that window.open() happens first, and the AJAX requests to start QEMU-VNC happens second.
I half expected this to cause a race condition where the websockets connection is dropped by websockify, because the backend QEMU-VNC port either has not been assigned yet, or has been assigned but is returning TCP RST because it's not running yet.
However, I've done quite a bit of testing, and have not run into the race condition even once, so it seems like a very good solution.
(Not sure why the race condition does not occur. Maybe websockify is able to wait until the port is available before connecting or something?)
Anyway, works great. Patch available if any interest.
The text was updated successfully, but these errors were encountered: