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
Describe the bug
Some users will see a blank popup instead of a popup with content.
To Reproduce
Steps to reproduce the behavior:
Open two chrome windows.
in one window, click the prax icon to manually activate the prax attached popup.
in the other window, visit a frontend and perform an action that will trigger a prax dialog popup.
the triggered dialog popup will open.
sometimes, the triggered dialog popup will render a blank page until closed.
Expected behavior
The dialog popup should display something.
Screenshots
Additional context
this is due to a race condition between promiscuous listeners attached by every popup.
the types of the popups do not matter, but a common situation is a manually opened 'attached popup' in one window which has lost focus but still persists, and an affected 'dialog popup' automatically opened by another window later.
the popup-root listener is attached by every popup regardless of route or content. any popup-root listener will claim any detected popup control message, and any incoming request is consumed by the first listener to claim it. each listener persists after activation and may activate again.
when a dialog remains blank, the wrong popup has handled the message. you can inspect the zustand state of the receiving popup to see the message data, and activate the function stored there to respond to the message. closing the receiving popup will fail the message.
the blank popup will not contain the input message and can't respond.
a popup will not clobber or mutate its state upon a repeat message of the same type - the handler will claim the message, but the slice will presently throw if asked to store another request of the same type.
a popup will not render UI that might respond to an unexpected message of a different type - the handler will claim the message, and the slice will successfully store it. but the routes activate specific components, and those components refer to slices which are unambiguous.
i don't know what determines listener activation sequence.
the present work on #174 does not affect this issue.
The text was updated successfully, but these errors were encountered:
Describe the bug
Some users will see a blank popup instead of a popup with content.
To Reproduce
Steps to reproduce the behavior:
Expected behavior
The dialog popup should display something.
Screenshots
Additional context
this is due to a race condition between promiscuous listeners attached by every popup.
the types of the popups do not matter, but a common situation is a manually opened 'attached popup' in one window which has lost focus but still persists, and an affected 'dialog popup' automatically opened by another window later.
the popup-root listener is attached by every popup regardless of route or content. any popup-root listener will claim any detected popup control message, and any incoming request is consumed by the first listener to claim it. each listener persists after activation and may activate again.
when a dialog remains blank, the wrong popup has handled the message. you can inspect the zustand state of the receiving popup to see the message data, and activate the function stored there to respond to the message. closing the receiving popup will fail the message.
the blank popup will not contain the input message and can't respond.
a popup will not clobber or mutate its state upon a repeat message of the same type - the handler will claim the message, but the slice will presently throw if asked to store another request of the same type.
a popup will not render UI that might respond to an unexpected message of a different type - the handler will claim the message, and the slice will successfully store it. but the routes activate specific components, and those components refer to slices which are unambiguous.
i don't know what determines listener activation sequence.
the present work on #174 does not affect this issue.
The text was updated successfully, but these errors were encountered: