-
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: Room - Side panel does not close when clicking outside of panel. #38015
fix: Room - Side panel does not close when clicking outside of panel. #38015
Conversation
Signed-off-by: Krishna Gupta <belivethatkg@gmail.com>
@hoangzinh Please copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button] |
src/components/Modal/BaseModal.tsx
Outdated
@@ -117,6 +118,9 @@ function BaseModal( | |||
return; | |||
} | |||
|
|||
if (onBackdropPress) { | |||
onBackdropPress(); | |||
} | |||
onClose(); |
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.
@Krishna2323 should it be?
if (onBackdropPress) {
onBackdropPress();
} else {
onClose();
}
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.
Nope, onClose
must be called but onBackdropPress
is optional.
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.
then it would be weird @Krishna2323. Let's say
<Modal
onClose={do_on_close}
onBackdropPress={do_on_bd_press)
/>
If you haven't read the implementation details of this Modal component, we might thought when backdrop press, it's only do_on_bd_press
. We aren't aware it would call onClose
as well.
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 think we should give decisions to users, where they can decide if they want to call do_on_close
when bd press as well
<Modal
onClose={do_on_close}
onBackdropPress={do_on_bd_press && do_on_close)
/>
or
<Modal
onClose={do_on_close}
onBackdropPress={do_on_close && do_on_bd_press)
/>
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.
Yeah, it looks confusing, let me check again.
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.
cc @Krishna2323 just in case you missed my comment
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.
@hoangzinh, apologies for the delay. I believe we can proceed as you suggested without causing any regressions at this time. However, my main concern is regarding the difference between onClose and onBackdropPress callbacks.
In Scenario 1: If we update states when the onClose
callback is triggered and we have specific actions for when the user clicks on the backdrop, solely calling onBackdropPress
might not achieve the intended functionality.
In Scenario 2: If we update states when either onClose
or onBackdropPress
is called, it might be better to only utilize one of these to avoid potential regressions due to redundant function calls.
At the moment, I'm inclined towards only calling one of these callbacks as you suggested, but I'd like to confirm our decision once more. Please let me know your thoughts on how we should proceed.
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 think:
- In scenario 1: we can call
onClose
insideonBackdropPress
Let's simplify it, just go with only calling one of these callbacks
, then we can update later on our way.
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.
@hoangzinh, updated.
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.
@hoangzinh friendly bump
Signed-off-by: Krishna Gupta <belivethatkg@gmail.com>
Reviewer Checklist
Screenshots/VideosAndroid: NativeScreen.Recording.2024-03-18.at.18.35.28.android.movAndroid: mWeb ChromeScreen.Recording.2024-03-18.at.18.30.47.android.chrome.moviOS: NativeScreen.Recording.2024-03-18.at.18.33.05.ios.moviOS: mWeb SafariScreen.Recording.2024-03-18.at.18.32.02.ios.safari.movMacOS: Chrome / SafariScreen.Recording.2024-03-18.at.18.26.13.web.movMacOS: DesktopScreen.Recording.2024-03-18.at.18.27.45.desktop.mov |
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.
LGTM
@Krishna2323 please fix the conflict so we can review and merge |
@danieldoglas, conflict resolved. |
✋ 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 https://github.com/danieldoglas in version: 1.4.55-0 🚀
|
🚀 Deployed to staging by https://github.com/danieldoglas in version: 1.4.55-0 🚀
|
@Krishna2323 @danieldoglas @hoangzinh — appears to be a bug in the fix per this GH 👍 |
🚀 Deployed to production by https://github.com/AndrewGable in version: 1.4.55-3 🚀
|
Details
Fixed Issues
$ #34394
PROPOSAL: #34394 (comment)
Tests
Offline tests
QA Steps
PR Author Checklist
### Fixed Issues
section aboveTests
sectionOffline steps
sectionQA steps
sectiontoggleReport
and notonIconClick
)myBool && <MyComponent />
.src/languages/*
files and using the translation methodSTYLE.md
) were followedAvatar
, I verified the components usingAvatar
are working as expected)StyleUtils.getBackgroundAndBorderStyle(theme.componentBG)
)Avatar
is modified, I verified thatAvatar
is working as expected in all cases)Design
label so the design team can review the changes.ScrollView
component to make it scrollable when more elements are added to the page.main
branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTest
steps.Screenshots/Videos
Android: Native
android_native.mp4
Android: mWeb Chrome
android_chrome.mp4
iOS: Native
ios_native.mp4
iOS: mWeb Safari
ios_safari.mp4
MacOS: Chrome / Safari
web_chrome.mp4
MacOS: Desktop
desktop_app.mp4