New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Bug] Nested components inside Modals don't respond to user events #201
Comments
Thanks for reporting this @fudgeboy2000. It seems to be related to a similar issue reported on Blazored Typeahead Blazored/Typeahead#149. I've replicated the issue reported with the Typeahead locally and working on a fix right now. An early observation is it doesn't appear to be due to the focus trap, the behaviour is still displayed when it's disabled. |
The issue is because there is an I'm not sure why this is causing this behaviour as the keyup handler for the modal only handles escape keypress events... |
Thanks for the update Chris. These things can get super messy. It's not a massive issue - I can just roll back to 4.1 for now. |
The only sensible way I see around this is to remove the ability to dismiss the modal using the escape key. Now I'm looking at this it doesn't make much sense to have that function anyway as, for example, hitting escape when using Blazored Typeahead should dismiss the suggestion box. But if it were used inside the modal, it would dismiss the modal as well. |
Describe the bug
Not so much a bug, more of an interaction issue with other components.
Since updating from v4.1, nested components inside Blazored.Modal components don't respond to user events. For example, I'm using Radzen's Datepicker inside a Modal, and if I upgrade from v4.1 then the Datepicker appears but doesn't respond to mouse clicks.
To Reproduce
Steps to reproduce the behavior:
Add radzen datepicker to Blazored Modal.
Expected behavior
Datepicker to work as expected.
Hosting Model (is this issue happening with a certain hosting model?):
Additional context
I understand that this just could be an issue with the two components interacting in a bad way and might not be a bug with Blazored Modal as such. I do wonder if it's related to the new work on the focus trap in v5.0, and if so would it be possible to allow a parameter to opt out of the focus trap functionality?
The text was updated successfully, but these errors were encountered: