mWeb: Keep the focus state of the composer when closing three dots menu in report header#28899
Conversation
| <ThreeDotsMenu | ||
| anchorPosition={styles.threeDotsPopoverOffset(props.windowWidth)} | ||
| menuItems={threeDotMenuItems} | ||
| shouldSetModalVisibility={false} |
There was a problem hiding this comment.
On mWeb, we focus on the main composer by the modal state. This led to the inconsistency between mWeb and native apps.
App/src/pages/home/report/ReportActionCompose/ComposerWithSuggestions.js
Lines 477 to 481 in 25f7ac1
src/pages/home/HeaderView.js
Outdated
| onIconPress={() => { | ||
| const {composerRef, editComposerRef, isFocused, isEditFocused} = ReportActionComposeFocusManager; | ||
| if (isFocused()) { | ||
| composerRef.current.blur(); | ||
| } else if (isEditFocused()) { | ||
| editComposerRef.current.blur(); | ||
| } | ||
| }} |
There was a problem hiding this comment.
On native apps, the composer doesn't blur when we click on buttons. We need to blur it by code like we did here
App/src/pages/home/report/ReportActionCompose/ReportActionCompose.js
Lines 203 to 208 in 25f7ac1
I also blurred the edit composer to make consistency between mWeb and native apps.
There was a problem hiding this comment.
@ginsuma This change causes regression on mobile-web and native. When closing the modal, the composer doesn't re-focus in case when it was focused before. The issue is that when the composer was not focused, after opening and closing the modal, the composer shouldn't focus.
There was a problem hiding this comment.
@ArekChr I think whether the composer is focused or not if we open the three dots menu, the composer will blur. We only re-focus on some cases, like opening an emoji picker or adding actions.
But we also can restore the keyboard state if this is our expected behavior. On Desktop Web, we don't restore or keep the focus state when clicking on the three dots button.
There was a problem hiding this comment.
But we also can restore the keyboard state if this is our expected behavior
- Remove
onIconPressabove. - Add
onMouseDown={(e) => Browser.isMobile() && e.preventDefault()}toPressableWithoutFeedbackinThreeDotsMenuto keep the focus state.
There was a problem hiding this comment.
@ArekChr I will wait for your confirmation before pushing a new commit and recording new videos.
There was a problem hiding this comment.
@pecanoro any thoughts? I think that the composer should be refocused when it was focused before, like on the emoji picker
There was a problem hiding this comment.
I was testing it and in any other case, if the composer was focused and we open any modal or menu, it get's refocused on going back, so we should do the same with the 3 dots!
|
@ArekChr I updated the code to keep the focus state. |
Reviewer Checklist
Screenshots/VideosWebweb.movMobile Web - Chromeandroid.chrome.movMobile Web - Safariios.safari.movDesktopdesktop.moviOSNagranie.z.ekranu.2023-10-11.o.10.26.41.movAndroidNagranie.z.ekranu.2023-10-11.o.10.27.22.mov |
|
I can't test Android because of some build errors, will update video after fixing it |
ArekChr
left a comment
There was a problem hiding this comment.
As expected, it works on the mobile web, and nothing has changed on other platforms.
|
I mentioned in a comment that we should refocus the composer as we do for the other modals, but I see we just remove the focus completely. |
@pecanoro After closing the three-dots menu, we keep the focus state like before. Could you share with me which platform did you test? |
|
@pecanoro I re-uploaded android and iOS recordings |
|
If the composer is focused, open the 3 dots modal and close it, the composer is not focused again. Monosnap.screencast.2023-10-11.20-50-42.mp4 |
@pecanoro I thought that was expected behavior on Web/Desktop. We have a similar menu, and we just remove the focus when opening/closing this menu on Web/Desktop. I keep the current behavior and update the mWeb behavior in this PR. But if we need to keep the focus state on these platforms, too. Which should we choose?
I'm looking forward to hearing your idea. Thanks! |
|
@pecanoro The same behavior is on staging on the web and desktop platforms |
What do you mean by this? I see two different behaviors with the other two modals:
|
|
@pecanoro I mean that behavior on a web browser doesn't change compared to staging, The issue is to prevent focusing composer while opening and closing the dots modal, in the scenario when the composer was not focused before opening the modal on the mobile web |
|
@pecanoro, what is the next step here? |
|
I was doing some testing on mobile and it seems it's also pretty inconsistent, so we can leave it unfocused. |
| } | ||
| }} | ||
| onMouseDown={(e) => { | ||
| if (!Browser.isMobile()) { |
There was a problem hiding this comment.
One last request, can you explain here why we need this?
There was a problem hiding this comment.
@pecanoro, on Web and mWeb, the composer will blur if we click outside the text input. This is expected on Web, but not mWeb. On there, we want to keep the focus state like we did on native apps when closing the menu.
There was a problem hiding this comment.
Sorry, what I meant is, can you add a comment in the code before the if condition explaining that? 😄
|
✋ 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/pecanoro in version: 1.3.87-0 🚀
|
1 similar comment
|
🚀 Deployed to staging by https://github.com/pecanoro in version: 1.3.87-0 🚀
|
|
🚀 Deployed to production by https://github.com/francoisl in version: 1.3.87-12 🚀
|
|
🚀 Deployed to staging by https://github.com/pecanoro in version: 1.3.88-0 🚀
|
|
🚀 Deployed to production by https://github.com/chiragsalian in version: 1.3.88-11 🚀
|


Details
We no longer use the video chat button on the report header. We use the three dots menu instead. This PR keeps the focus state of the composer on mWeb when closing the three dots menu on the report header.
Fixed Issues
$ #26763
PROPOSAL: #26763 (comment)
Tests
Offline tests
N/A
QA Steps
Same as tests
PR Author Checklist
### Fixed Issuessection aboveTestssectionOffline stepssectionQA stepssectiontoggleReportand notonIconClick)myBool && <MyComponent />.src/languages/*files and using the translation methodWaiting for Copylabel for a copy review on the original GH to get the correct copy.STYLE.md) were followedAvatar, I verified the components usingAvatarare working as expected)/** comment above it */thisproperly so there are no scoping issues (i.e. foronClick={this.submit}the methodthis.submitshould be bound tothisin the constructor)thisare necessary to be bound (i.e. avoidthis.submit = this.submit.bind(this);ifthis.submitis never passed to a component event handler likeonClick)StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))Avataris modified, I verified thatAvataris working as expected in all cases)ScrollViewcomponent to make it scrollable when more elements are added to the page.mainbranch was merged into this PR after a review, I tested again and verified the outcome was still expected according to theTeststeps.Screenshots/Videos
Web
Screen.Recording.2023-10-09.at.1.21.13.PM.mov
Mobile Web - Safari
Screen.Recording.2023-10-09.at.1.34.42.PM.mov
Mobile Web - Chrome
Screen.Recording.2023-10-09.at.1.36.39.PM.mov
Desktop
Screen.Recording.2023-10-09.at.1.56.32.PM.mov
iOS
Screen.Recording.2023-10-09.at.1.21.52.PM.mov
Android
Screen.Recording.2023-10-09.at.3.45.19.PM.mov