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
In Safari, new jupyterlab browser tab constantly loops if an old browser tab is still open #6921
Comments
Can confirm I also have this issue. Often have to quit my terminal application even if I have closed the tabs that Jupyterlab was running in. |
I can also confirm this on jlab 1.0.4, Safari 12.1.2. @afshin fixed similar symptoms we saw on Firefox a while ago. My server log looks something like this:
etc. When I open the Safari debug panel, it does seem to resolve after just a few tries at a new workspace, and I find this error several times in the js console: CC @afshin |
I have a similar issue with my jupyterlab installation. I deleted the ~/.jupyter/lab/workspaces folder and the problem still persists. Edit: I should add, that this container has worked before in the same configuration, so I am a bit amiss what changed (it being a container and me deleting the .jupyter/lab/workspaces files) |
Solution: "Have you tried turning it off and on again." That is restarting the workstation and not only the docker container.... |
Thanks for the suggestions. I've restarted my machine multiple times since this cropped up and it hasn't solved it. I will try deleted workspaces folder AND restarting and report back. |
Same issue. Happens all the time inadvertently. |
Just bumped into this as well on our jupyterhub installation,closing other tabs doesn't fix it for me, I can't find any way to make jupyterlab load from jupyterhub on Safari. Working fine in Firefox. |
@jasongrout's suggestion helped me to get unstuck. Good workaround. |
Oh, I did not notice that another browser window was open with Jupyter lab running -- as it was in another window (not just another tab). Once I found and closed it, that took care of the crazy restart loop. |
I spent some time investigating this. I think this is a bug in Safari, but I think we can work around it. We use local storage events to communicate between browser tabs in order to see if there are any other tabs with a particular workspace name. The standard says that local storage events are only supposed to be triggered by local storage changes from other tabs. However, Safari sometimes triggers these events from changes by the current tab. Here is an example illustrating this: <html>
<body>
<div id='report'>No events received</div>
<script>
let date = new Date().getTime();
let report = document.getElementById('report');
window.addEventListener('storage', ev => {
if (ev.key !== 'SOME KEY') {
return;
}
if (ev.newValue === date.toString()) {
report.innerText = `BUG: received my own local storage change (${date}) as an event.`;
} else {
report.innerText = `Another tab was reloaded with timestamp ${ev.newValue}`;
}
});
window.localStorage.setItem('SOME KEY', date);
</script>
</body>
</html> Open that page in two different Safari tabs and start refreshing each one alternately. It was pretty easy for me to get one of the tabs to indicate the bug was happening. Things worked fine in firefox and presumably would in Chrome too. A workaround is to manually ignore local storage events that we triggered. Even if we move to BroadcastChannel (see #7315), we'll still need to deal with this since Safari doesn't implement broadcast channel, so we'd have to fall back to something like local storage on Safari. |
Fixes jupyterlab#6921 We use local storage events to communicate between browser tabs in order to see if there are any other tabs with a particular workspace name. The standard says that local storage events are only supposed to be triggered by local storage changes from *other* tabs. However, Safari sometimes triggers these events from changes by the current tab. Here is an example illustrating this: ```html <html> <body> <div id='report'>No events received</div> <script> let date = new Date().getTime(); let report = document.getElementById('report'); window.addEventListener('storage', ev => { if (ev.key !== 'SOME KEY') { return; } if (ev.newValue === date.toString()) { report.innerText = `BUG: received my own local storage change (${date}) as an event.`; } else { report.innerText = `Another tab was reloaded with timestamp ${ev.newValue}`; } }); window.localStorage.setItem('SOME KEY', date); </script> </body> </html> ``` Open that page in two different Safari tabs and start refreshing each one alternately. It was pretty easy for me to get one of the tabs to indicate the bug was happening. Things worked fine in firefox and presumably would in Chrome too. A workaround implemented here is to manually ignore local storage events that we triggered. Even if we move to BroadcastChannel (see jupyterlab#7315), we'll still need to deal with this since Safari doesn't implement broadcast channel, so we'd have to fall back to something like local storage on Safari.
@jasongrout, I installed jupyterlab directly from the master branch to include your commit, but the problem still persists with Safari. It keeps looping forever, even when I don't have any tab open. Can you please let me know if this problem is fixed? Thank you. |
Can you just try installing in a clean environment from the newest alpha? If you are using conda:
and then go to help > about to make sure you are running the alpha. |
Just checking - if running from master, you have to use |
@jasongrout This bug also persists on my Ubuntu+Firefox machine. Last time it disappeared after a workstation restart, but that seems to be the only solution for now. The logs just show something like this:
Individual Notebooks still run just fine.
|
What version of firefox? |
|
Okay, thanks. Can you try the jupyterlab 1.2 RC? If you are using conda, you can install with |
or if you're using pip, you should be able to do |
@jasongrout I created a second docker image with the only difference being that I am using jupyterlab 1.2.0rc0 |
Neither does restarting Firefox. |
@dkuegler - I should have asked this at the start - can you open a new issue? This specific issue was working around a bug in Safari, which was fixed. It may be that there are similar issues in firefox, but it's more difficult to keep track of new possible problems items on old resolved issues. |
(and as for something else to try - can you try in firefox private mode with no ff extensions installed?)...and let's continue the conversation on a new issue. |
Describe the bug
Jupyterlab window in a browser (Safari on macOS 10.14.6) constantly loops and refreshes until you close the previously open jupyterlab notebook.
To Reproduce
jupyterlab
instancejupyterlab
instance in the terminal (Ctrl+C)jupyterlab
instance on the same portExpected behavior
New jupyterlab window should load just fine even if a previous one is still open.
Desktop (please complete the following information):
Additional context
May be linked to #6079 ?
Command Line Output
The text was updated successfully, but these errors were encountered: