-
Notifications
You must be signed in to change notification settings - Fork 2.9k
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
Fix: Modal and screen closing with single esacpe
keypress
#5889
Conversation
esacpe
keypressesacpe
keypress
src/components/ScreenWrapper.js
Outdated
|
||
/** Details about any modals being used */ | ||
modal: PropTypes.shape({ | ||
/** Indicates if there is a modal currently visible or not */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NAB: Your property names are pretty self-describing, which is great, so the doc comment is unnecessary.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comments are necessary for props based on the styleGuide.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good and tests pass 👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure the exact reproduction steps, but I am still able to trigger the Esc bug occasionally. It's shown at the end of this clip, I close the confirmation dialog a couple of times, then hit escape which closes both the modal and screen.
EscapeStillClosing.mov
Will check... |
@Julesssss I have found the issue. Thanks for reporting. we set App/src/libs/Navigation/AppNavigator/AuthScreens.js Lines 98 to 104 in 1d1323c
Now, I need a way to differentiate the Alert modals and Modal screens (they are not really a modal). Apart from this, there is currently no supported way to override the escape handler. What I am planning is
To keep the backward compatibility I will set the Do you think this is fine? I don't see any other way right now. |
OK, I have pushed the suggested code above. Now there is another issue.
Why? Fix: Create another key something like |
@Julesssss Thoughts? |
Hmm, that's unfortunate. I think you're on the right track with the solution, I just have a few suggestions for naming:
|
I don't think we should do that yet. We need a common prop to keep the app behavior as it is. Otherwise, we will have to use both props where
Really a good suggestion. Now, I think that we only need So |
Cool, sounds good. But would you mind explaining why
|
* @param {Boolean} isVisible | ||
*/ | ||
function willAlertModalBecomeVisible(isVisible) { | ||
Onyx.merge(ONYXKEYS.MODAL, {willAlertModalBecomeVisible: isVisible}); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, @Julesssss I did this change. Now I think we don't need to rename the isVisible
as this is still valid for both alert and screenModal context.
This is ready for review @deetergp @Julesssss . |
esacpe
keypressesacpe
keypress
src/components/ScreenWrapper.js
Outdated
|
||
/** Details about any modals being used */ | ||
modal: PropTypes.shape({ | ||
/** Indicates if there is a Alert modal currently visible or not */ |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
NAB: The idea here is that we know the modal will be made visible, right? I was going to suggest that we add '...currently visible or about to become visible'. But I'm not sure that it's necessary TBH.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tests well 👍
✋ This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release. |
🚀 Deployed to staging by @Julesssss in version: 1.1.8-10 🚀
|
🚀 Deployed to production by @roryabraham in version: 1.1.10-2 🚀
|
This PR could have prevented this bug #18558. The |
I guess that was not a use case when this PR was created (2 years back). |
Details
Fixed Issues
$ #5769
Tests | QA Steps
esc
button.Tested On
Screenshots
Web | Desktop
output_file.mp4
Mobile Web
Desktop
iOS
Android