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

Localstorage #11

Closed
Jelmerro opened this issue Feb 13, 2019 · 0 comments · Fixed by #22
Closed

Localstorage #11

Jelmerro opened this issue Feb 13, 2019 · 0 comments · Fixed by #22
Assignees
Labels
enhancement New feature or request

Comments

@Jelmerro
Copy link
Owner

Localstorage is already managed by chromium, but it should be possible to access it like so:

  • A list per domain of everything in the localstorage, where entries can be deleted one at a time or per domain
  • Settings for autoclearing the localstorage when closing a tab after x seconds delay
  • A setting to clear everything in the localstorage when closing Vieb

Unlike cookies, electron does not provide an api for it. This means that this issue needs to be solved in one of the following ways:

  • Access the files directly with level (files are in /home/user/.config/Vieb/IndexedDB and /home/user/.config/Vieb/Local Storage, but it's not a proper solution I think)
  • Only allow a full wipe of these folders, optionally after closing Vieb and forget about displaying a proper entry list
  • A different approach I'm not aware of

Sadly, most npm packages claiming to access the localstorage are simply alternative implementation of the localstorage specification, which are not suitable for this use case. The packages actually accessing the localstorage are mostly based on executeJavaScript, which will only find the localstorage for the currently opened website. This method is therefor also not considered a solution to the problem.

Please feel free to suggest alternative options to access the chromium localstorage in a more fitting way, as these are the only two options I could think of. Out of these two, I would likely go for the second one, because it's much easier to implement and a lot less hacky.

@Jelmerro Jelmerro added the enhancement New feature or request label Feb 13, 2019
@Jelmerro Jelmerro added this to the Nice to haves milestone Feb 13, 2019
@Jelmerro Jelmerro modified the milestones: Nice to haves, 0.3.0 May 13, 2019
@Jelmerro Jelmerro self-assigned this May 13, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

Successfully merging a pull request may close this issue.

1 participant