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

In Safari, new jupyterlab browser tab constantly loops if an old browser tab is still open #6921

Closed
firasm opened this issue Jul 29, 2019 · 22 comments · Fixed by #7316
Closed

In Safari, new jupyterlab browser tab constantly loops if an old browser tab is still open #6921

firasm opened this issue Jul 29, 2019 · 22 comments · Fixed by #7316
Labels
status:resolved-locked
Milestone

Comments

@firasm
Copy link

@firasm firasm commented Jul 29, 2019

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

  1. Launch a jupyterlabinstance
  2. Leave the browser tab open
  3. Kill the jupyterlab instance in the terminal (Ctrl+C)
  4. launch another jupyterlab instance on the same port
  5. New window that opens until the previous one is closed.

Expected behavior
New jupyterlab window should load just fine even if a previous one is still open.

Desktop (please complete the following information):

  • OS: macOS 10.14.6
  • Browser: Safari
  • JupyterLab: 1.0.4

Additional context
May be linked to #6079 ?

Command Line Output
[I 20:06:38.120 LabApp] Use Control-C to stop this server and shut down all kernels (twice to skip confirmation).
[C 20:06:38.134 LabApp] 
To access the notebook, open this file in a browser:
    file:///Users/fmoosvi/Library/Jupyter/runtime/nbserver-9604-open.html
Or copy and paste one of these URLs:
    http://localhost:8888/?token=8d65bf2b089d8d59057b59c8bc08c0a8719c33dbef1ba7f8

[I 20:06:40.443 LabApp] 301 GET /lab/workspaces/auto-B/?clone (::1) 1.12ms
[I 20:06:40.981 LabApp] 301 GET /lab/workspaces/auto-2/?clone=auto-B (::1) 0.78ms
[I 20:06:41.449 LabApp] 301 GET /lab/workspaces/auto-s/?clone=auto-2 (::1) 1.53ms
[I 20:06:41.726 LabApp] 301 GET /lab/workspaces/auto-e/?clone=auto-s (::1) 0.77ms
[I 20:06:41.982 LabApp] 301 GET /lab/workspaces/auto-F/?clone=auto-e (::1) 1.08ms
[I 20:06:42.300 LabApp] 301 GET /lab/workspaces/auto-G/?clone=auto-F (::1) 0.83ms
[I 20:06:42.683 LabApp] 301 GET /lab/workspaces/auto-A/?clone=auto-G (::1) 0.82ms
[I 20:06:42.963 LabApp] 301 GET /lab/workspaces/auto-0/?clone=auto-A (::1) 0.70ms
[I 20:06:43.256 LabApp] 301 GET /lab/workspaces/auto-2/?clone=auto-0 (::1) 0.64ms
[I 20:06:43.518 LabApp] 301 GET /lab/workspaces/auto-y/?clone=auto-2 (::1) 0.64ms
[I 20:06:43.877 LabApp] 301 GET /lab/workspaces/auto-N/?clone=auto-y (::1) 0.71ms
[I 20:06:44.135 LabApp] 301 GET /lab/workspaces/auto-Y/?clone=auto-N (::1) 1.39ms
[I 20:06:44.402 LabApp] 301 GET /lab/workspaces/auto-T/?clone=auto-Y (::1) 0.58ms
[I 20:06:44.693 LabApp] 301 GET /lab/workspaces/auto-z/?clone=auto-T (::1) 0.71ms
[I 20:06:44.925 LabApp] 301 GET /lab/workspaces/auto-2/?clone=auto-z (::1) 0.62ms
[I 20:06:45.215 LabApp] 301 GET /lab/workspaces/auto-K/?clone=auto-2 (::1) 0.70ms
[I 20:06:45.453 LabApp] 301 GET /lab/workspaces/auto-r/?clone=auto-K (::1) 0.59ms
[I 20:06:45.812 LabApp] 301 GET /lab/workspaces/auto-t/?clone=auto-r (::1) 0.83ms
[I 20:06:46.252 LabApp] 301 GET /lab/workspaces/auto-8/?clone=auto-t (::1) 0.73ms
[I 20:06:46.725 LabApp] 301 GET /lab/workspaces/auto-f/?clone=auto-8 (::1) 1.01ms
[I 20:06:47.009 LabApp] 301 GET /lab/workspaces/auto-s/?clone=auto-f (::1) 1.09ms
[I 20:06:47.385 LabApp] 301 GET /lab/workspaces/auto-b/?clone=auto-s (::1) 0.71ms
[I 20:06:47.707 LabApp] 301 GET /lab/workspaces/auto-c/?clone=auto-b (::1) 1.02ms
[I 20:06:48.182 LabApp] 301 GET /lab/workspaces/auto-2/?clone=auto-c (::1) 1.49ms
[I 20:06:48.571 LabApp] 301 GET /lab/workspaces/auto-K/?clone=auto-2 (::1) 0.65ms
[I 20:06:48.894 LabApp] 301 GET /lab/workspaces/auto-C/?clone=auto-K (::1) 0.67ms
[I 20:06:49.243 LabApp] 301 GET /lab/workspaces/auto-I/?clone=auto-C (::1) 0.68ms

@tpollok-kainos
Copy link

@tpollok-kainos tpollok-kainos commented Aug 9, 2019

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.

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Aug 9, 2019

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:

[I 05:57:18.963 LabApp] 301 GET /lab/workspaces/auto-b/?clone=auto-e (::1) 2.22ms
[I 05:57:19.231 LabApp] 301 GET /lab/workspaces/auto-k/?clone=auto-b (::1) 0.49ms
[I 05:57:19.551 LabApp] 301 GET /lab/workspaces/auto-U/?clone=auto-k (::1) 3.04ms
[I 05:57:19.840 LabApp] 301 GET /lab/workspaces/auto-C/?clone=auto-U (::1) 0.80ms
[I 05:57:20.091 LabApp] 301 GET /lab/workspaces/auto-g/?clone=auto-C (::1) 0.48ms

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:

Screen Shot 2019-08-09 at 5 55 37 AM

CC @afshin

@jasongrout jasongrout added this to the 1.1 milestone Aug 9, 2019
@jasongrout jasongrout changed the title New jupyterlab browser tab constantly loops if an old browser tab is still open In Safari, new jupyterlab browser tab constantly loops if an old browser tab is still open Aug 9, 2019
@blink1073 blink1073 removed this from the 1.1 milestone Aug 27, 2019
@blink1073 blink1073 added this to the 1.2 milestone Aug 27, 2019
@dkuegler
Copy link

@dkuegler dkuegler commented Sep 30, 2019

I have a similar issue with my jupyterlab installation.
Jupyter Lab 1.0.9 in a custom docker container
Firefox 68.0.2 (64 bit) on Ubuntu 16.04.6

I deleted the ~/.jupyter/lab/workspaces folder and the problem still persists.
restarting the container -- I have also treid to create a different workspace, but the issue extends to different workspaces.

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)

@dkuegler
Copy link

@dkuegler dkuegler commented Sep 30, 2019

Solution: "Have you tried turning it off and on again."

That is restarting the workstation and not only the docker container....

@firasm
Copy link
Author

@firasm firasm commented Oct 1, 2019

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.

@thomaslima
Copy link

@thomaslima thomaslima commented Oct 6, 2019

Same issue. Happens all the time inadvertently.

@barche
Copy link

@barche barche commented Oct 6, 2019

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.

@techrah
Copy link

@techrah techrah commented Oct 7, 2019

@jasongrout's suggestion helped me to get unstuck. Good workaround.

@techrah
Copy link

@techrah techrah commented Oct 8, 2019

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.

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Oct 10, 2019

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.

jasongrout added a commit to jasongrout/jupyterlab that referenced this issue Oct 10, 2019
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.
@tangbinh
Copy link

@tangbinh tangbinh commented Oct 22, 2019

@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.

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Oct 22, 2019

Can you just try installing in a clean environment from the newest alpha?

If you are using conda:

conda create -n jlab-120a3 -c conda-forge/label/prerelease-jupyterlab jupyterlab=1.2.0a3
conda activate jlab-120a3
jupyter lab

and then go to help > about to make sure you are running the alpha.

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Oct 22, 2019

I installed jupyterlab directly from the master branch to include your commit,

Just checking - if running from master, you have to use jupyter lab --dev-mode and you see a red bar at the top - otherwise you are just running the latest release.

@dkuegler
Copy link

@dkuegler dkuegler commented Oct 28, 2019

@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.
I am running Jupyter in a docker container and neither restarting the container (and therefore jupyter) nor restarting Firefox (or both at the same time fixes the issue...

The logs just show something like this:

[I 15:45:42.051 NotebookApp] 301 GET /lab/workspaces/auto-I/?clone (172.17.0.1) 0.61ms
[I 15:45:42.488 NotebookApp] 301 GET /lab/workspaces/auto-u/?clone=auto-I (172.17.0.1) 0.57ms
[I 15:45:42.891 NotebookApp] 301 GET /lab/workspaces/auto-L/?clone=auto-u (172.17.0.1) 0.58ms
[I 15:45:43.335 NotebookApp] 301 GET /lab/workspaces/auto-8/?clone=auto-L (172.17.0.1) 0.64ms
[I 15:45:43.786 NotebookApp] 301 GET /lab/workspaces/auto-m/?clone=auto-8 (172.17.0.1) 0.63ms

Individual Notebooks still run just fine.

59d74f09262d:/workspace$ jupyter --version
jupyter core     : 4.5.0
jupyter-notebook : 6.0.1
qtconsole        : not installed
ipython          : 7.8.0
ipykernel        : 5.1.2
jupyter client   : 5.3.1
jupyter lab      : 1.1.4
nbconvert        : 5.6.0
ipywidgets       : 7.5.1
nbformat         : 4.4.0
traitlets        : 4.3.2

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Oct 28, 2019

What version of firefox?

@dkuegler
Copy link

@dkuegler dkuegler commented Oct 28, 2019

@jasongrout

landau:~$ firefox --version
Mozilla Firefox 70.0

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Oct 28, 2019

Okay, thanks. Can you try the jupyterlab 1.2 RC?

If you are using conda, you can install with conda create -n jlab12rc -c conda-forge/label/prerelease-jupyterlab jupyterlab=1.2.0rc0

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Oct 28, 2019

or if you're using pip, you should be able to do pip install --pre jupyterlab

@dkuegler
Copy link

@dkuegler dkuegler commented Oct 29, 2019

@jasongrout I created a second docker image with the only difference being that I am using jupyterlab 1.2.0rc0
However, I did find more indications:
While I was having this issue with Firefox, switching to Chrome (i.e. a clean browser) the loop does not appear, so it must be in the communication between FF and JL. -- Clearing Cookies "Forget this website" does not fix the issue with FF.

@dkuegler
Copy link

@dkuegler dkuegler commented Oct 29, 2019

Neither does restarting Firefox.

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Oct 29, 2019

@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.

@jasongrout
Copy link
Contributor

@jasongrout jasongrout commented Oct 29, 2019

(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.

@lock lock bot added the status:resolved-locked label Nov 28, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Nov 28, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status:resolved-locked
Projects
None yet
Development

Successfully merging a pull request may close this issue.

9 participants