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

Restore workspace open files across multiple instances #7983

Open
gbodeen opened this issue Jun 9, 2020 · 10 comments
Open

Restore workspace open files across multiple instances #7983

gbodeen opened this issue Jun 9, 2020 · 10 comments
Labels
bug bugs found in the application electron issues related to the electron target monaco issues related to monaco

Comments

@gbodeen
Copy link
Contributor

gbodeen commented Jun 9, 2020

Bug Description:

Expected: When re-opening a workspace, the editor pane should display the same open files as were open last time the workspace was in use.

Actual: Instances of Theia after the first open the workspace but do not restore tabs. This error appears in the console:

image

This becomes relevant when Theia is bundled as an application (for distribution similar to VS Code). Users will commonly try to launch multiple instances of the application, each for use with a different workspace, but currently this will not give the expected user experience.

I'm not 100% confident this is a bug rather than an intentional, temporary limitation. In any case, VS Code does not have this limitation.

Steps to Reproduce:

  1. In a local copy of the Theia repo, run yarn && yarn start:electron. Assuming you've previously opened multiple different workspaces, use File > Open Recent Workspace to launch new windows with those workspace. This works as expected, displaying the files that were last open. Close all instances.
  2. In two terminals, run yarn start:electron to start separate instances. The first instance will display the files that were last open; the second will not. Use File > Open Recent Workspace in each instance for additional examples; the first instance will continue to restore open files, because it has access to the indexedDB, and the second will not restore them.

Additional Information

  • Operating System: RHEL7
  • Theia Version: 1.2.0 plus subsequent commits as of 2020-06-09.
@akosyakov
Copy link
Member

The error is weird. We have a guard that if indexeddb is not available then we don't use it. It seems in your env there is indexeddb support but it throws internal errors. Could you dig what is causing internal errors?

@akosyakov akosyakov added 🤔 needs more info issues that require more info from the author bug bugs found in the application monaco issues related to monaco labels Jun 10, 2020
@kittaakos
Copy link
Contributor

kittaakos commented Jun 10, 2020

Maybe it's a generic issue with electron: electron/electron#10792 (comment)

Edit: here is another useful comment:

I saw if an electron process is running in the background and you're starting a new electron process, the IndexedDB is locked for the first process. So I get an error: "UnknownError: Internal error opening backing store for indexedDB.open.".

@kittaakos kittaakos added the electron issues related to the electron target label Jun 10, 2020
@gbodeen
Copy link
Contributor Author

gbodeen commented Jun 18, 2020

Here is a partial solution:

If you need completely separate IndexedDB, use different partition partition: "persist:part1", partition: "persist:part2", ... see https://www.electronjs.org/docs/api/browser-window#new-browserwindowoptions

In a couple places there's code using session.defaultSession to return the default session object, which I presume can be replaced by session.fromPartition("persist:partitionName"). However, in my initial tests, the websocket connection gets refused, indicating I'm missing something.

@akosyakov
Copy link
Member

Could you test whether it is still the issue with Electron 9? Here is a PR which we hope to land next month: #7968

@gbodeen
Copy link
Contributor Author

gbodeen commented Jun 23, 2020

I tested that PR branch this afternoon on RHEL 7.8. The issue still exists in Electron 9.

Incidentally, as I do not have root access, I had to run that branch as yarn && yarn start:electron --no-sandbox. Without the no-sandbox flag, the yarn start:electron command prints a message:

[6277:0623/151502.149582:FATAL:setuid_sandbox_host.cc(158)] The SUID sandbox helper binary was found, but is not configured correctly. Rather than run without sandboxing I'm aborting now. You need to make sure that /repo/theia/node_modules/electron/dist/chrome-sandbox is owned by root and has mode 4755.

@kittaakos
Copy link
Contributor

I am also interested in this issue and will try to share my findings here.

@kittaakos kittaakos self-assigned this Jun 24, 2020
@kittaakos kittaakos removed the 🤔 needs more info issues that require more info from the author label Jun 24, 2020
@gbodeen
Copy link
Contributor Author

gbodeen commented Jun 30, 2020

The PR to allow electron-main process customization is almost a solution for us, except for the error below. If we set theia.backend.config.singleInstance = true in package.json, then the attempted second instance defers to the first instance, and the first instance opens a second window. The new window therefore has full access to workspaces and themes. That's great! However, it throws an error:

image

It looks like it's interpreting process.execPath as a workspace, maybe due to expecting the wrong number of arguments on the command line.

In the existing master branch, by contrast, singleInstance mode simply causes the window belonging to the first instance to focus. No second window is opened.

@paul-marechal
Copy link
Member

@gbodeen Do you get this error when running Theia from sources or is it from a bundled app?

@paul-marechal
Copy link
Member

paul-marechal commented Jun 30, 2020

@gbodeen I think the issue you've reported has been fixed by the latest commit pushed on that branch/PR.

@kittaakos
Copy link
Contributor

I think the issue you've reported has been fixed

I can confirm this. I had the same problem and we fixed it here.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug bugs found in the application electron issues related to the electron target monaco issues related to monaco
Projects
None yet
Development

No branches or pull requests

4 participants