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

Fix loss of local storage in Electron #6313

Merged
merged 1 commit into from
Oct 7, 2019

Conversation

westbury
Copy link
Contributor

@westbury westbury commented Oct 2, 2019

What it does

As a result of #904 the window path name is prefixed to the local storage key. However in the Electron version this can break the persistence of local storage. This is because the window path name changes each time the program is run (when run in production mode). Therefore I suggest reverting to exclude pathname if running in Electron.

How to test

Run an Electron app on Linux. Change something that is persisted in local storage. Exit the app, closing down Electron and restart (do not just refresh). Run in production because in development the path name is the path to index.html for the desktop app.

Review checklist

Reminder for reviewers

Copy link
Member

@vince-fugnitto vince-fugnitto left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure adding the dependency to core would be the way forward.
(the CI is failing because of it)

packages/core/src/browser/storage-service.ts Outdated Show resolved Hide resolved
packages/core/src/browser/storage-service.ts Outdated Show resolved Hide resolved
Signed-off-by: Nigel Westbury <nigelipse@miegel.org>
@westbury westbury force-pushed the electron-local-storage branch from 688ea18 to 85af2b0 Compare October 3, 2019 10:29
@akosyakov akosyakov added the electron issues related to the electron target label Oct 3, 2019
@spoenemann
Copy link
Contributor

Wouldn't we rather bind a different implementation in the Electron Inversify module instead of checking at runtime?

@westbury
Copy link
Contributor Author

westbury commented Oct 4, 2019

Wouldn't we rather bind a different implementation in the Electron Inversify module instead of checking at runtime?

Good question, and that was how I was originally going to implement this. I chose to do it this way because:

  1. There is precedent in testing at runtime, eg FileDownloadCommandContribution, and using Inversify seemed overkill for a single line of code.
  2. I have no use-case for extenders needing to further customize the key prefix. I could simply rebind a class that extends StorageService and overriding prefix(). If that is what you have in mind then be aware that this could complicate things should extenders be rebinding StorageService for other purposes. So better would be to extract a separate interface and binding just for the prefix.

Copy link
Contributor

@kittaakos kittaakos left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This is because the window path name changes each time the program is run (when run in production mode)

Nice catch!

Run an Electron app on Linux.

I have verified it on Windows but the window.location.pathname has the same effect.

👍 Thank you for the fix.

@thegecko
Copy link
Member

thegecko commented Oct 7, 2019

@spoenemann Are you happy I merge this?

@spoenemann
Copy link
Contributor

👍

@thegecko thegecko merged commit 24f5d20 into eclipse-theia:master Oct 7, 2019
@westbury westbury deleted the electron-local-storage branch February 28, 2020 17:03
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
electron issues related to the electron target
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants