I’m trying to share links to a JupyterHub instance via /user-redirect/..., and apart from the fact that the redirect is lost upon login when it uses nbgitpuller (which is a JupyterHub/nbgitpuller issue I’m investigating separately), JupyterLab’s file navigation feature with /tree doesn’t work in conjunction with auto-generated workspaces.
The issue manifests even if I cut /user-redirect out of the loop, i.e. even if I just try to open a URL which is already targeted at a specific user. Say the URL ends with /user/test-user/lab/tree/test.ipynb:
The first time I visit that in a browser, JupyterLab loads test.ipynb, as expected, and removes the part of the URL starting with /tree from the browser location.
When I do it a second time in another tab however, a new workspace is first automatically created, but test.ipynb is not loaded and the part of the URL starting with /tree stays in the location. I have to refresh the page in order to nudge JupyterLab to go forward with these two things.
The strange thing is that when I run JupyterLab locally (i.e. not behind JupyterHub), this works as expected. Judging by the GitHub tracker, this has been an issue in the past, but has since been fixed. Which leads me to think it may have been fixed in a way which doesn’t play nice with JupyterHub or additional proxies?
Or maybe these features are generally finicky and the fact that they don’t work reveals that there’s something wrong with my Nginx/JupyterHub setup? I’d be grateful for any suggestions on where to look, and happy to provide additional information, though I realize there’s a lot of moving parts here, so it’s not a particularly appealing bug to tackle
This might or might not be related? If it is related, it might make it more reproducible / more easily tested…
I’ve noticed if I still happen to have JupyterLab 2.01 open from a repo using MyBinder.org (which at its heart is a JupyterHub), the directed links to a specific notebook don’t work when I launch again. (It just brings up the launcher page when the session starts.) If I launch with no other JupyterLab open in my browser, then it forwards to the specified notebook.
Initially, this made me think with JupyterLab 2.0 that the forwarding mechanism by URL via MyBInder.org wasn’t working. But it turned out I had a forgotten window open.
This sounds like the same issue to me! If you already have a session open in another browser tab, then opening a new one should autogenerate a new workspace (you can check if the URL in that case contains /workspaces/auto-...).
So at least it looks like it might not be a config snafu on my part?
I hit the same issue. Has this been solved in a newer version of jupyterlab? I couldn’t find any issues related to this in the github repo. Is there a workaround?
@aflag , you may want to check out this recent post, as well as, some of the earlier & subsequent discussion in another thread because I think getting Binder to open the right notebook with JupyterLab using a link and workspace behavior may be related.
It seems dependent on browsers. Perhaps? I’m still unclear 100% on that since my version of Firefox was old. Besides that, one work-around is to encourage your users to open things in incognito/stealth mode. Or encourage them to refresh, (see below). Or try to leave (or demonstrate) guidance on how to navigate to notebooks.
The @dlukes here in the original post in this thread said reloading helped. And indeed Command-R on my mac in Chrome did trigger a hard refresh and correct loading of the specified notebook (via workspaces behind-the-scenes) in a MyBinder launched instance when I already had a fresh instance launched in another Chrome window.
You don’t say if you are actually using JupyterLab locally or through JupyterHub. The initial post said JupyterLab locally was fine. So I assumed you were using JupyterHub. Binder is a public BinderHub, which is a JupyterHub with extra tech (such as repo2docker, etc.) and so some of the findings with Binder and workspaces, I thought may be pertinent and that’s whyI redirected you to that other thread.
You also don’t say which version of JupyterLab you are using. I’m still still not sure there isn’t an issue with workspaces in JupyterLab 3. See my ‘caveat’ here where I describe that none of the ideas seems to be allowing the JupyterLab demo from the ‘Try Jupyter’ site Project Jupyter | Try Jupyter. So maybe the work-around would be to use older JupyterLab? Don’t know for sure on that as this uses an imported workspace and others don’t.
