This pull request has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Pinging @jrieke as you have commented on the related ticket.

@jrieke please look into this as it would be super helpful!

Hi @jrieke, Let me know how we can take this forward. I have been using my solution successfully in production for over a month. But would love it if this gets merged.

Hey, thanks for your PR and sorry for the wait!

We considered adding this in the past but have not done so for now. The problem is that viewers can still make the app rerun by pressing "R" or clicking on "Rerun" in the app menu. So having a dismissible option might give a false sense of security that viewers won't be able to get out of the dialog when, in fact, they can. Let me play around with your PR in the next few days and see how it feels in practice! Do you have any opinion on this? Would also be fantastic so see some code examples of how/for which use cases you use this!

OK just tried this out and also read up on the issues again. Yeah, I can definitely see that this is helpful for some scenarios where you want to guide the users toward not closing the dialog, but it's not the end of the world if they rerun the app and, therefore, close the dialog. But I still fear that some users might e.g. use this as a login modal and not realize that users can get out of it easily by rerunning the app through the menu.

So I think the options we have are:

1. Disallow rerunning through the menu/keyboard shortcut altogether. I think it's not likely we'll do that since it would be a big behavior change.
2. Not launch this. Also not great because I see valid use cases!
3. Launch this but add a disclaimer to the docs saying that users can still get out of the dialog by rerunning the app.
4. Disable the "Rerun" menu item while a dialog with dismissible=True is shown. This would be pretty neat but I'm not sure if it isn't pretty complicated to implement. Seems like we do this here if the server is disconnected but it might be hard to pipe the information that a dialog is open into that piece of the code. @raethlein any opinion on this idea?

I've tested these changes and when dismissable=False we can't click on the “the app chrome” (the three dots menu on the top right). I think that solve your concern @jrieke

Oh right. I think you can still press R on the keyboard to rerun, no?

Pressing R on the keyboard will rerun the app.

However, if we do not make this change and keep dialogs dismissable, they would still be unsuitable for a login page (or as an entry point to a Streamlit app) since users can simply close the modal.
And usually after a successful login, we save some kind of state to denote the user is logged in, if the session state is not set (because the dialog was closed forcefully by pressing R), the user will remain in the logged-out state.

Offtopic question for @souvikmaji, how can I install your fork instead of the official one? I tested your changes by changing directly the py file in .venv\Lib\site-packages\streamlit\elements, but I don't know how to do it in an azure web app deployment.

However, if we do not make this change and keep dialogs dismissable, they would still be unsuitable for a login page (or as an entry point to a Streamlit app) since users can simply close the modal.
And usually after a successful login, we save some kind of state to denote the user is logged in, if the session state is not set (because the dialog was closed forcefully by pressing R), the user will remain in the logged-out state.

Yup, agree with that. The danger I see though is that people think this prevents app reruns, write their app in a way where e.g. private data is getting shown after a login dialog is closed, and then that data is getting exposed if viewers press R. For sure, that's an edge case but it's one that potentially touches security (or rather, where there is a common use case that could touch security), so I'm a bit hesitant to just ship this. I think we should at least figure out if there is a good way to prevent the rerun. I'll also discuss this with the team next week to get some more opinions!

@frarteaga you can install my fork by running pip install streamlit-dialog.
I made it available in PyPI to install it in production easily.
But since it has not been officially merged yet, use it at your own risk and discretion.

🎉 Snyk checks have passed. No issues have been found so far.

✅ security/snyk check is complete. No issues have been found. (View Details)

✅ license/snyk check is complete. No issues have been found. (View Details)