Skip to content
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

Workspace interface behavior unclear #3673

Closed
joshjob42 opened this issue Jan 17, 2018 · 18 comments
Closed

Workspace interface behavior unclear #3673

joshjob42 opened this issue Jan 17, 2018 · 18 comments

Comments

@joshjob42
Copy link

@joshjob42 joshjob42 commented Jan 17, 2018

Hello all,

I don't know where else to ask this, so I thought I'd create a new issue, and if I'm being stupid and this is easy it'll be closed quickly.

As far as I understand, if I navigate to /lab/workspaces/<workspace_name> either workspace <workspace_name> will be loaded from memory and opened or a new workspace will be created. I assume that the new workspace that opens should open with just the launcher, however it seems currently to duplicate the workspace I already have open in another tab.

Moreover, if I close a tab in one workspace (say a notebook, console, editor, etc...), let's call it , and then reload the browser page for another workspace, say , the change in is reflected in and vice versa. That is, not only does navigating to lead me to a page with the same layout as when opening from a fresh JupyterLab session, the two seem to remain connected at all times. It doesn't appear there's any workspaces being made at all, just a single view on one underlying workspace that can be viewed in diverging ways in different browser tabs only for as long as each respective browser tab is open and hasn't been reloaded.

Is this the expected behavior? ie workspaces aren't semi-permanent (so long at least as the underlying JupyterLab process is running), but just different temporary views? Or am I experiencing an actual issue? From #3490 it appears that it's meant to be closer to semi-permanent, reloadable, etc. I realize workspaces aren't prominently displayed at the moment, but I'm eager to use them to separate different projects I'm currently working on, so any help would be most appreciated.

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Jan 19, 2018

IIRC, a creating a new workspace will take your existing state as the starting state. That way you can set up things how you want, then go to the workspace URL to snapshot it. Or you can easily fork another workspace by just changing the workspace name.

Do you have jupyterlab open in two browser tabs? There may be some conflict going on in the storage for a workspace. Can you try your experiments with just one browser tab?

Loading

@jasongrout jasongrout added this to the Reference milestone Jan 19, 2018
@joshjob42
Copy link
Author

@joshjob42 joshjob42 commented Jan 19, 2018

Yes I was using JupyterLab in two browser tabs, as I assumed part of the value of workspaces was to have different views open at once.

I tried again, shutting down my instance of Lab, restarting it, and set up a configuration. Then I went to workspaces/primary in the same browser tab and it copied the configuration as expected. I then navigated to workspaces/secondary, again in the same tab, and modified the configuration. After that, navigating back to both main and /primary I saw the changes I'd made in the /secondary workspace, all in the same browser tab.

That's not the expected behavior, right? It does seem like somehow there's a storage conflict going on, though it doesn't make much sense to me why.

Loading

@afshin
Copy link
Member

@afshin afshin commented Jan 19, 2018

JupyterLab is not really currently designed in a way that makes working in multiple tabs predictable because the "working memory" of your application state is window.localStorage, which means that the state will be shared by multiple tabs. This is why you're seeing seemingly unpredictable results when you have multiple tabs open. We have had some conversations about launching native windows that have a child/parent relationship with each other, but the main model of user interaction with JupyterLab is within a single window/tab.

If you go to workspace that does not exist, its starting point is your current state as it exists in local storage.

Loading

@afshin
Copy link
Member

@afshin afshin commented Jan 19, 2018

Currently, if you have a need that can only be addressed by multiple windows, you can open two different browsers or you can have one incognito window and one non-incognito window. If they use the same workspace URL, then each new thing you do in one window will clobber what the other window had saved and since saves have no way of "notifying", you will have unexpected results. So to truly have two different views, you'd need to use different workspace URLs (or no workspaces at all).

Loading

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Jan 19, 2018

Another option is to use separate Firefox tab containers to separate different local storages.

Loading

@joshjob42
Copy link
Author

@joshjob42 joshjob42 commented Jan 19, 2018

Well I guess I don't need multiple windows, but it'd be nice. However, as I mentioned in my last post this isn't just when I have multiple tabs open. Even when I use a single tab and navigate between workspaces I still get this clobbering behavior.

Can someone else open up a JupyterLab instance, set it up, then navigate to a new workspace name, change the configuration, and then go back and see if the original workspace has now been changed? I don't need multiple windows to get this clobbering behavior, I just have to switch from one workspace to another serially in a single browser tab.

Loading

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Jan 20, 2018

  1. I agree it would be great to get it working in multiple tabs

  2. I'll test the single-tab version for you. I thought I did a while ago and it worked great. Are you on jlab 0.31.1?

Loading

@joshjob42
Copy link
Author

@joshjob42 joshjob42 commented Jan 20, 2018

Yes I am. Thank you very much for your help!

Loading

@afshin
Copy link
Member

@afshin afshin commented Jan 21, 2018

@joshjob42 @jasongrout I see this behavior in my current build. I wonder if we have a regression. I'll look into it.

Loading

@afshin
Copy link
Member

@afshin afshin commented Jan 21, 2018

Okay, I see. This behavior actually is working as intended. The only thing to consider is that there is a debounce interval (WORKSPACE_SAVE_DEBOUNCE_INTERVAL) that basically waits for two seconds before saving your workspace after you've made modification, the idea being to not flood the server with workspace requests.

So if you look at the screencap below, the behavior works as intended as long as I wait two seconds after modifying my workspace.

workspaces

Loading

@joshjob42
Copy link
Author

@joshjob42 joshjob42 commented Jan 21, 2018

I'm not sure how you did that behavior, but I waited for quite a long time and still get the clobbering behavior. Here's a link where you can watch my screencapture of it. https://drive.google.com/file/d/19MGEW1utzECbhqQrE23i-rqhbpYi7TWS/view

Loading

@afshin
Copy link
Member

@afshin afshin commented Jan 22, 2018

@joshjob42 I'm sorry, but I can't understand exactly what's going on in your session because the URL bar is not showing. I will try this behavior not using my current build, which is based off of the latest master branch and does have some updates to the areas of code that affect this behavior.

It may turn out to be the case that the behavior in the current development branch that will soon be released is different than the last release.

Loading

@mehd-io
Copy link

@mehd-io mehd-io commented Feb 25, 2018

Hi @afshin , any update on this issue? I tried with the latest version (0.31.8) with only one tab and couldn't reproduce the behaviour as you showed. When I come back to a previous created workspaces, it just copied again from the current one.
jupyterlab_workspace4

Loading

@joshjob42
Copy link
Author

@joshjob42 joshjob42 commented Feb 28, 2018

I couldn't for the life of me figure out how to do that sort of gif video capture so thank you @mehd-io . I just wanted to chime in and say that I'm also still observing this behavior even with the latest JupyterLab release. "Workspaces" just don't see to separate even when you only access them sequentially in a single tab and wait for arbitrary time periods (much longer than two seconds) between modifying the workspace and switching to a different one. They still just clobber each other no matter what I do as far as I can tell.

Loading

@afshin
Copy link
Member

@afshin afshin commented Mar 3, 2018

@joshjob42 The behavior you captured is indeed incorrect. I think I know what is happening: there was a bug in an earlier version of jupyterlab_launcher that basically meant it was not saving workspaces if a workspaces folder did not exist on your system. That bug has been fixed (cf. jupyterlab/jupyterlab_server#40). So if you upgrade your version of jupyterlab_launcher, that should resolve this issue.

On the larger issue of multiple windows, we are targeting it for 1.0: cf. #4041

Loading

@mehd-io
Copy link

@mehd-io mehd-io commented Mar 3, 2018

@afshin , so I've just upgraded the jupyterlab_launcher and still got exactly the same behaviour as showed above, under jupyter 0.31.8.

Loading

@afshin
Copy link
Member

@afshin afshin commented Mar 3, 2018

Can you open your browser's developer tools and see if there are any errors in your JS console?

Loading

@afshin
Copy link
Member

@afshin afshin commented Jul 2, 2018

Fixed in #4708

Loading

@afshin afshin closed this Jul 2, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Aug 8, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants