jupyterlab-hub
jupyterlab-hub copied to clipboard
jupyterhub
Usability quark
This is not really a bug, but rather a usability issue that I have seen. Currently when a user clicks on the hub menu --> control panel, the jupyterhub control panel opens in a new tab/window and leaves the current jupyterlab session open. If the user then clicks on stop my server from the control panel with the jupyterlab session open, the notebook server will get torn down, but then spawned up pretty much immediately afterwards because the existing jupyterlab session in the other tab is trying to hit the old notebook server. So now a new notebook server is started up but without the users knowledge.
It also happens on my cluster. Changing '_blank' to '_self' in window.open on line 59 and 67 would solve this.
I'm not sure what the right solution is here. Setting the target to _self seems like the wrong thing to do because you would lose any JupyterLab application state that doesn't persist across page loads.
Wouldn't the act of navigating away from the page bring up the alert box asking the user if they are sure they want to do that and warning them they could lose state? Not sure if that is a browser specific feature or something that is actually coded into the lab application, but if I try to close the jupyterlab window I get an alert each time.
I was thinking about maybe embedding the jupyterhub actions into commands in jupyterlab so you never actually have to leave the main UI, but that seemed like it would have a weird workflow.
@tkinz27, yes, that is the ideal scenario. However, even with our core extensions I'm sure there are places where restore doesn't work 100%. Having the hub actions in a panel, where stopping the server also calls window.close() might work.
I would like to add that this is confusing when you restart your server, e.g. if a new image is available. The usage is stop followed by a start at which point you are prompted for a workspace URL, because the old (Lab) window is open in another tab. I don't think a target is necessary in this case. If you lose work, it's probably ok, because stopping a server is a user initiated action.
