rusk
rusk copied to clipboard
dusk-network
web-wallet: Improve experience when invalid Gas Limit is set on initialization and the user accesses Settings
Summary
I am seeing a problem with the experience, in case an invalid gas limit has been set in the ENV.
If the user tries to access the Settings, the Back button will be disabled, as the Gas Limit is invalid. However, as the user hasn't changed anything in the view, I think it's not immediately clear why the Back is disabled.
This is more of a corner case, as the user has to have supplied an invalid value in their ENV. However, it is possible that the ENV gets messed up on Production, which would lead to users experiencing this.
Open to discussion.
You make a valid point here, but still unsure if we should act on it now, or rather wait for some change I'm expecting like contracts defining their own gas settings limits (upper / lower) and defaults.
You make a valid point here, but still unsure if we should act on it now, or rather wait for some change I'm expecting like contracts defining their own gas settings limits (upper / lower) and defaults.
Sure, it's a low-priority item. Just wanted to track it.
This is actually a feature not a bug, I made it like this for the following edge case. We or the user change the ENVs which invalidate the preferred gas settings in the app. As we do not show that the ENVs have changed the only way to make the user change the preferred gas settings is to force him to change them when he goes to the settings page.
This is actually a feature not a bug, I made it like this for the following edge case. We or the user change the ENVs which invalidate the preferred gas settings in the app. As we do not show that the ENVs have changed the only way to make the user change the preferred gas settings is to force him to change them when he goes to the settings page.
The user will be forced to change them once they trigger a flow that makes use of the properties.
And progressing to the next step being disabled due to invalid value is a well-known behavior, whereas disabling the back on the Settings doesn't feel intuitive.
Side note: I think that, invalid values for the Gas have been set for whatever reason, the Gas Settings pane should be expanded by default, otherwise why the user cannot proceed is not immediately clear.
This is actually a feature not a bug, I made it like this for the following edge case. We or the user change the ENVs which invalidate the preferred gas settings in the app. As we do not show that the ENVs have changed the only way to make the user change the preferred gas settings is to force him to change them when he goes to the settings page.
The user will be forced to change them once they trigger a flow that makes use of the properties.
And progressing to the next step being disabled due to invalid value is a well-known behavior, whereas disabling the back on the Settings doesn't feel intuitive.
Indeed, but I do not know what the user will do first in the app so that is why I forced the user in the settings page to update the gas limits.
Side note: I think that, invalid values for the Gas have been set for whatever reason, the Gas Settings pane should be expanded by default, otherwise why the user cannot proceed is not immediately clear.
This is strange as the pane should open if the gas limits are invalid, this indeed is a bug.
This is strange as the pane should open if the gas limits are invalid, this indeed is a bug.
I just checked, it seems to be working fine. Not sure what happened before.