Bug: White Wootility Window because of Wootility user data write permissions

[Rocky04]

Wootility Version

xx

Firmware Version

xx

Keyboard type

all

Issue description

Showing only a plain white after starting the Wootility.

Steps to reproduce

Restricting file permission for the Wootility user data.

Known Workaround

Uninstall the Wootility with deleting the user data.

Possible fix

Implementing a correct error handling if there is a problem with loading the data to prevent the deadlock. The app should check if the files are present and how the access permissions are. If the app can read the files but without write permission, it should create a new copy with a versioning suffix to it. If it can't even read the files, it should inform the user that it can't load the previous data and so that the Wootility created new default files for it. If it can't create new files, it should inform the user about that.
Regardless why, it should not happen that the Wootility is stuck on a white screen as long as there isn't a major programm problem and user data aren't in that category.

[Rocky04]

I have this problem too when I toggle XInput or nKRO if I use the Wooting in a VM. Maybe because it took longer to detect the device because of the hand over from the host to the guest.

[PastaJ36]

Fixed in Wootility >v3.5.2

[Rocky04]

Where is still a problem if the Wootility has no read permission. This can happen like after an OS upgrade or if the user has copied the file from another PC.

When I remove all the permissions for the file beta_profiles.json (by removing the inheritance so there is no valid permission entry for it) and try to open the Wootility I can only see a white window and need to kill the app.

Because this isn't a major error the Wootility should still work but maybe can promt a light info to the user.

Edit:

[2020-04-29 07:53:25.245] [info] 3.5.3-alpha
[2020-04-29 07:53:25.271] [info] undefined
[2020-04-29 07:53:25.698] [info] Update for version 3.5.3-alpha is not available (latest version: 3.5.3-alpha, downgrade is disallowed).
[2020-04-29 07:53:26.708] [error] Uncaught Error: C:\Users\user\AppData\Roaming\wootility-alpha/beta_profiles.json: EPERM: operation not permitted, open 'C:\Users\user\AppData\Roaming\wootility-alpha/beta_profiles.json'

Edit 2:
If there is only a read permission the app don't inform the user that the changes to the inactive profiles get lost. This isn't good practice...
[2020-04-29 08:07:43.352] [error] Uncaught Error: EPERM: operation not permitted, open 'C:\Users\user\AppData\Roaming\wootility-alpha/beta_profiles.json'

[PastaJ36]

In the next Wootility version we're changing the way profiles and settings are stored to avoid any issues with file permissions. We're planning on using Redux Persist which will allow faster init and no files required.

[Rocky04]

What does what mean? Is the data not stored locally anymore then? Can the JSON data of the profiles still accessed somewhere?

[PastaJ36]

Would it be nice to still have it easily accessed? I can see we can change the storage engine: https://github.com/rt2zz/redux-persist#storage-engines, what do you think @simon-wh ?

[simon-wh]

@Rocky04 By default redux-persist uses LocalStorage from the web API's to save the configs. It is possible for us to have it use a backend that saves to disk similar to how it behaves currently. I believe it serialises as JSON still and the LocalStorage does save it locally in AppData, but I haven't looked into if it is possible to easily read it on disk. Redux persist is nice as it gives us a lot more flexibility for the future with where we deploy Wootility as it helps decouple us from node/electron/native only APIs.

How important do you think it is to have access to the configs on disk? Is being able to backup/copy over settings enough or is it needed to be able to read/modify it for most use cases?

[Rocky04]

I like that it's possible to have it local accessible.

• Easier for me to debug / look into things.
• A skilled user can customise the profile, like using a custom curve.
• People can archive complete sets of profiles without the hassle to deal with a lot of sharing codes.
• Easier for third parts tools (not that there some out there as far as I know) to interact with archived profiles.

Having a feature to import / export a profile by an external file would be great as a replacement though. Even it adds complexity again and so a possible point of failure.

[simon-wh]

Hmmmm, I like the idea of import/export, as that is something that would be retained with a more flexible Wootility deployment and is a decent bit more user-friendly. However, it isn't a complete replacement to local access as you lose the ability to manually recover configs/profiles in case of a critical error as well as the possibility of third party tool access like you mention.

I think I'll have a play around with some of the options and see how well they work

[Rocky04]

Accessing a file which is owned from another app is a bit tricky anyway.

So a good way to go around that is to maybe offer an (Rest-) API. But I would think this hasn't any priority yet and don't need to be considered for now. So as long as there is something to import / export the profiles as JSON data so it can be inspected / manually changed I'm fine with it.

I talked with Ed about the idea to change a profile on the Wootabase so it can be downloaded from that site and manually inserted into the Wootility. I don't know if he would implement it later on. Because I like the idea of a profi like tool to customise profiles, like custom curves and so on. For now I do it my self manually.

[Rocky04]

The Wootility 4.2.X now shows different JavaScript error depending on the permission problems but the app still tries to start and so it loads its sub processes instead of just quiet.

This leads to a bad instance which resides and needs to be killed manually. If the permissions are fixed and if the app is started again a different instance is created. So instead of a white window now there is none while the app is kind of a zombi.

[simon-wh]

I think this can be closed as now it can only occur through altering permissions to electron generated files which I think is not something we need to worry about too much. Unless there is a real-world situation where the permissions get broken by themselves, if the only way to trigger it is with manual permission altering I feel like it's a non-issue

[Rocky04]

Hmm, in my option the Wootility should take care and never should enter such a state where nothing is possible anymore. This isn't a critical error and so I think the Wootility should just continue. It can of course show a warning that it can't access the old data and so needed to created new files. Or enter a zombi like state where it's not possible to open a new instance.

This was just an example how it can be forced, some users actually had the issue and I needed to tell them to delete the entire folder in order to fix it. Maybe because they copied their user folder to another machine or upgraded their Win version.