Repository navigation
Android back button support and a new web platform feature proposal #875
Description
Hi react-modal maintainers,
The Chrome team is investigating how to make modals on the web better. One area we've identified is that it's hard for libraries to get the correct behavior on Android of having the back button close a modal. (This can also be an issue on other platforms, e.g. iOS VoiceOver has a special gesture for closing modals.) As such, we have a new proposal at WICG/proposals#18 which is looking for signals of web developer interest, to see if it's worth investing in.
I wasn't able to determine from your issue tracker or your source code if this was something you or your users had run into, so I thought I'd open a new issue to get your feedback. Is this problem something your library is interested in? If so, do you have any thoughts on the proposed API? It's actually partially implemented in Chrome behind a flag (with the old name ModalCloseWatcher), so you could try it out.
Best,
-Domenic
Activity
diasbruno commentedon May 18, 2021
Hi @domenic,
react-modalusers can handle when to display modal usingisOpenproperty. If it's possible to be notified when theback buttonis pressed or register a callback to keep track of it, the user can manage this behavior - when appropriate.react-modal could handle this like it handles the
ESCbutton. We have a propertyshouldCloseOnEsc, possibly,shouldCloseOnBackButton.domenic commentedon May 20, 2021
Oh, very interesting! The way we designed the
CloseWatcherAPI, it doesn't tell you what the close signal is: whether it's an Android back button, a desktop Esc key, an iOS VoiceOver gesture, or a PlayStation square button. They all give the same signal.Do you think your users would specifically want the ability to control each of these independently, with separate properties like you describe? Our thinking was that bundling them together would give users a more expected behavior.
diasbruno commentedon May 20, 2021
It would be nice to provide an API where users could also receive the
CloseWatch's signals or events...It wouldn't be easy to find a proper API, because we'll need to provide the fallback in case we don't have the watcher.
I'll try to have a better look on API side to find more options...
dvoytenko commentedon Jun 17, 2021
Should this use case be any different than
shouldCloseOnEsc? TheCloseWatchershould allow implementing the same closing pattern asshouldCloseOnEsc.gustavopch commentedon Sep 7, 2024
It seems the
closeevent is already supported in some browsers: https://caniuse.com/mdn-api_closewatcher_close_eventdiasbruno commentedon Sep 7, 2024
Although this is experimental stuff, it would be really interesting to see how this plays out for real.
Anyone want to make a POC for this?
diasbruno commentedon Sep 7, 2024
Also, there are 2 events of interest:
oncloseandonclosedwhich are 2 events for different purposes.diasbruno commentedon Sep 12, 2024
I'm going to close this because this feature is yet experimental. Thank you all for your considerations.
gustavopch commentedon Sep 12, 2024
Could be implemented under an
experimental_flag like RR/Remix does with theirunstable_andfuture_flags.I mean, I believe it's experimental exactly so it can gather feedback from real-world usage (like what would happen in a library such as this one) before stabilizing the API, no? Maybe @domenic can advise.
diasbruno commentedon Sep 12, 2024
I'd prefer a branch to test it, instead of push and maintain compiler flags.
gustavopch commentedon Sep 12, 2024
I wonder if a branch would be harder to maintain compared to a flag. Because the flag is like literally
if (config.experimental_closeWatcher) { /* attach the listener and do something when it's called */ }somewhere in the code. A branch, on the other hand, brings extra CI/CD concerns, requires constant merge/rebase work to be kept up-to-date.Well... I wonder if even a flag is really needed to be honest. It's just progressive enhancement. And if the CloseWatcher API is removed for some reason in the future, it's just graceful degradation.
diasbruno commentedon Sep 12, 2024
The branch is just for a POC.
noahm commentedon Feb 6, 2026
This is something that recently came up for us at Twitch, and I took some time to prepare a draft PR (#1074)to help move the discussion forward. For now it's just an example of a naive adoption of the new API, but that does have some issues that I expand on more in the PR description.
I think the most realistic path forward is probably something along this path, and if there's interest I can explore that with a second branch.