You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
(a) When a video page is visited and we have a password in local storage associated with its series, but not with the video id directly. Then the first request will not send a password, and only in a second request (once we have the series id to look up the password), the video is unlocked. In between, the password prompt is shown. This only happens once, as then the password is also associated with the event ID.
(b) A video block has the same problem but a bit worse: here, we can never send the password in the initial request, as we only know to show the blocks of a realm, so we cannot look up any passwords before receiving the information what blocks even exist.
(c) When navigating away from a realm page with a video block, while the new route loads, the old realm page component renders the password prompt for video blocks instead of the player. I don't know why this "reverts" to showing the password prompt while loading the new route.
For (a) and (b), we should somehow show in the password prompt, that a request is on its way. Otherwise, when the request takes a long time, the user might already input the password and then it suddenly unlocks on its own. One could also potentially use the local relay store to check if the series ID is already cached, at least for (a).
For (c), we need to investigate why this is happening.
The text was updated successfully, but these errors were encountered:
This is caused by three distinct things:
(a) When a video page is visited and we have a password in local storage associated with its series, but not with the video id directly. Then the first request will not send a password, and only in a second request (once we have the series id to look up the password), the video is unlocked. In between, the password prompt is shown. This only happens once, as then the password is also associated with the event ID.
(b) A video block has the same problem but a bit worse: here, we can never send the password in the initial request, as we only know to show the blocks of a realm, so we cannot look up any passwords before receiving the information what blocks even exist.
(c) When navigating away from a realm page with a video block, while the new route loads, the old realm page component renders the password prompt for video blocks instead of the player. I don't know why this "reverts" to showing the password prompt while loading the new route.
For (a) and (b), we should somehow show in the password prompt, that a request is on its way. Otherwise, when the request takes a long time, the user might already input the password and then it suddenly unlocks on its own. One could also potentially use the local relay store to check if the series ID is already cached, at least for (a).
For (c), we need to investigate why this is happening.
The text was updated successfully, but these errors were encountered: