I have just become introduced to Jupyterlab through the GoPiGo robot and I have seen some issues regarding Firefox and Chrome.
When I first loaded Jupyterlab from the robot as a total newbie having never seen JupyterLab, I was very frustrated to find that any attempt to create a new text file or notebook gave me a 403 forbidden error. My default browser is Firefox Developer Edition. After some research I found on github some discussion of others who had the 403 problem and one suggestion was to use Chrome instead of Firefox and once I did that everything was fine.
What I surmise happened is that when the jupyterlab server first launched on DexterOS, it was “in” some read-only folder – I don’t know what – but the file browser panel was showing me nothing but a couple of files whose names I think started with underscore. After opening with Chrome the file browser had me in the home folder and I could see all the files and folders that I should see and I could no longer find the two files I first saw. Subsequently Firefox also behaves properly.
My second issue has to do with installing JupyterLab on OS X. I have posted a separate issue about pip3 not installing /usr/local/bin/jupyterlab. But this issue has to do with ~/Library/Jupyter/runtime/nbserver-78747-open.html. With Firefox opening that html file after launching the JupyterLab server does not redirect me to the server and does not show me a link. With Chrome it does show me a link that takes me to the server.
So I am just getting started but already I have seen a couple of issues where Chrome works and Firefox does not and I am wondering why that might be the case and what other problems one might encounter in the future.
Hello fellow Firefox user 
I submitted a patch for this here. This means that it will be fixed in the next release.
OK thanks. Do you have any thoughts about the 403 issue I saw with Jupyterlab on Dexter Industries Dexter OS?
Both of these issues sound like they are issues with the configuration and the underlying web server, not with the JupyterLab frontend itself.
The first issue sounds like a misconfiguration of where the notebook server was launched. My shot-in-the-dark guess is that chrome vs firefox is a red herring, and that somehow the server was relaunched in the correct directory (especially since ff worked fine later). That is a question for the GoPiGo folks, though.
The second issue is with the underlying notebook server (the Jupyter Notebook project, which provides the webserver used by JupyterLab), and as mentioned, apparently a fix was merged.
Rest assured that many of us core JLab devs use Firefox as our primary browser, and it is well supported.
Thanks Jason, I am still in the early stages of learning about JupyterLab but I do know more than I did 4 days ago when I first posted the questions.
Now I would not say that the 403 error has anything to do with Firefox vs Chrome.
With Dexter Industries DexterOS, you can enter JupyterLab via a link that puts you in a hidden directory /.lessons_python/1_Getting_Started which is not owned by jupyter. No doubt that is how I got in with Firefox, without really appreciating what was happening.
When I was using Chrome, I must have gone in with a different link that left me in the jupyter home directory.
I also understand now that when you create a new file or a new notebook, jupyter immediately wants to save that file in the current directory, as opposed to waiting until the user asks to save the file and the user gets a choice of where to save the file.
So it makes sense that I would get a 403 error if the current directory was something not owned by jupyter.
I’m hoping to understand better what happens when you have multiple connections to the same server.
I have learned that jupyter saves the state of the server in various “workspaces” and so if you make multiple connections to the server even from different browsers, you should see pretty much the same state with the same workspace and I understand that with OS X at least, the workspace is given by the url.
I would expect that would also be the case with jupyter on DexterOS though I think there could only ever be one workspace. If I had a different current directory in the file browser of one connection would that change the current directory in some or all other corrections? I will do some testing on that.
So the 403 error is behind me now and the problem that is bugging me on DexterOS is that I cannot reliably open a terminal tab. It always opens but only sometimes does it work.
No doubt this is a DexterOS issue but if you have any thoughts about why the terminal would fail I would love to hear them.
Sorry, I don’t have any ideas about that right now.
Dexter Industries engineers believe its a jupyter bug. I’m having the problem now and I can’t get it to work. Is there something I could look at on the front end and report back to you?
My issue now is with the python kernels and terminal taking a long time to start up on Jupyterlab on DexterOS when using Firefox. I know you are not responsible for DexterOS but it is a Jupyter issue and it does involve Firefox vs Chrome.
What I find when hosting Jupyterlab on OS X is that I cannot open a second connection to the server with the same workspace and the same browser. If however I use a different browser I can open a second connection with the same workspace. Except maybe it’s not really the same workspace if the server maintains different workspaces with the same url for different browsers.
What I find when hosting Jupyterlab on DexterOS is that if I open a connection to the server using the Chrome browser the python kernels for the ipynb files I have open are immediately “ready” and the terminal works also immediately.
But if I open a connection using the Firefox browser the kernels for the ipynb files show busy and the terminal gives no prompt. If I wait at least 5 and as many as 10 minutes, the ipynb kernels become “ready” and sometime later the terminal gives me a prompt.
I see this behavior even if I replace the DexterOS on the flash drive with a fresh copy and that makes me wonder where Jupyter maintains the workspaces since they do apparently persist and they do appear to be browser specific.
If you have any ideas about how to investigate this issue I will be happy to pass them along to the Dexter support people.
My last reply should have been directed to you.
The server does not maintain a separate workspace per browser. We don’t support opening the same workspace in different browsers simultaneously - there is no mechanism for synchronizing them.