Android back button support and a new web platform feature proposal

[domenic]

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

[diasbruno]

Hi @domenic,

react-modal users can handle when to display modal using isOpen property. If it's possible to be notified when the back button is 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 ESC button. We have a property shouldCloseOnEsc, possibly, shouldCloseOnBackButton.

[domenic]

react-modal could handle this like it handles the ESC button. We have a property shouldCloseOnEsc, possibly, shouldCloseOnBackButton.

Oh, very interesting! The way we designed the CloseWatcher API, 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]

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]

Should this use case be any different than shouldCloseOnEsc? The CloseWatcher should allow implementing the same closing pattern as shouldCloseOnEsc.

[gustavopch]

It seems the close event is already supported in some browsers: https://caniuse.com/mdn-api_closewatcher_close_event

[diasbruno]

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]

Also, there are 2 events of interest: onclose and onclosed which are 2 events for different purposes.

[diasbruno]

I'm going to close this because this feature is yet experimental. Thank you all for your considerations.

[gustavopch]

Could be implemented under an experimental_ flag like RR/Remix does with their unstable_ and future_ 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]

I'd prefer a branch to test it, instead of push and maintain compiler flags.

[gustavopch]

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]

The branch is just for a POC.