-
Notifications
You must be signed in to change notification settings - Fork 3k
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
[HOLD for payment 2025-01-18] [$250] iOS - Composer - Composer highlight flickers after closing attachment view #54615
Comments
Triggered auto assignment to @Beamanator ( |
💬 A slack conversation has been started in #expensify-open-source |
Triggered auto assignment to @sonialiap ( |
👋 Friendly reminder that deploy blockers are time-sensitive ⏱ issues! Check out the open `StagingDeployCash` deploy checklist to see the list of PRs included in this release, then work quickly to do one of the following:
|
Job added to Upwork: https://www.upwork.com/jobs/~021872607582148372045 |
Triggered auto assignment to Contributor-plus team member for initial proposal review - @ikevin127 ( |
This doesn't look big enough to be a blocker. Also I wonder if this was caused by #54189 🤔 just cuz it looks like a similar topic 😅 Though it doesn't look it necessarily affects the main composer which is what this issue is about 🤔 cc @QichenZhu @brunovjk in case y'all can take a look |
Thanks @Beamanator, I will take a look now |
Thanks!! |
@Beamanator I reverted our PR, but the issue here is still reproducible, IMO it doesn't seem related to our changes. I will continue investigating to find the root cause and a solution. Any additional insights are welcome! |
ProposalPlease re-state the problem that we are trying to solve in this issueComposer highlight (focus state styles) flicker after closing attachment view. What is the root cause of that problem?The flicher is caused by the logic implemented by PR #34404, which fixed issue #33466. The problem with the logic implemented by the PR is that in our issue's case, once we close the modal we already have logic in place to re-focus the input, but the additional logic added by the PR does that once again -> refocusing twice which causes our issue. Details
What changes do you think we should make in order to solve the problem?The problem is that we can't simply revert the PR logic since that would reintroduce issue #33466, therefore here's what I propose in order to have both issues fixed. We have to ensure that the You might ask: How can we distinguish between the report details page being opened from the header while edit input is focused, then closed to allow This is simple since we know that attachment modal is a const [modal] = useOnyx(ONYXKEYS.MODAL);
const prevIsModalVisible = usePrevious(modal?.isVisible); using this, we modify the // new imports
import {useOnyx} from 'react-native-onyx';
import ONYXKEYS from '@src/ONYXKEYS';
import usePrevious from './usePrevious';
export default function useResetComposerFocus(inputRef: MutableRefObject<TextInput | null>) {
const isFocused = useIsFocused();
const shouldResetFocusRef = useRef(false);
const [modal] = useOnyx(ONYXKEYS.MODAL); // <- add this like
const prevIsModalVisible = usePrevious(modal?.isVisible); // <- add this like
useEffect(() => {
if (!isFocused || !shouldResetFocusRef.current || prevIsModalVisible) { // <- add additional OR check to return early
return;
}
inputRef.current?.focus(); // focus input again
shouldResetFocusRef.current = false;
}, [isFocused, inputRef, prevIsModalVisible]);
return {isFocused, shouldResetFocusRef};
} this way we fix both issues, take a look: iOS: Native
What specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?N/A Result video (before / after)iOS: Native
@Beamanator If proposal makes sense, I'd like to work on this as Contributor and have somebody else step in as Reviewer, as per the C+ process doc:
|
Current assignee @Beamanator is eligible for the choreEngineerContributorManagement assigner, not assigning anyone new. |
ProposalPlease re-state the problem that we are trying to solve in this issue.Composer highlight flickers after closing attachment view What is the root cause of that problem?When I debugged this issue, I observed that it only occurs on native iOS and does not happen on native Android. Additionally, the behavior differs from the web version. The RCA is that we call textInput focus while the transition and animation are not complete, causing the highlight to appear and then disappear again. App/src/hooks/useResetComposerFocus.ts Line 14 in ae1c034
What changes do you think we should make in order to solve the problem?To resolve this issue, we just need to delay until the transition and animation are complete, then call focus, like this: App/src/hooks/useResetComposerFocus.ts Lines 14 to 15 in ae1c034
Add
https://github.com/Expensify/App/blob/93260a60eac6ce6200ec164fb967529db35ff071/src/libs
import type InputFocusResetHandler from './types';
const inputFocusResetHandler: InputFocusResetHandler = {
handleInputFocusReset: (inputRef, shouldResetFocusRef) => {
if (!inputRef.current || !shouldResetFocusRef.current) {
return;
}
inputRef?.current?.focus();
const resetFocusRef = shouldResetFocusRef;
resetFocusRef.current = false;
},
};
export default inputFocusResetHandler;
import {InteractionManager} from 'react-native';
import type InputFocusResetHandler from './types';
const inputFocusResetHandler: InputFocusResetHandler = {
handleInputFocusReset: (inputRef, shouldResetFocusRef) => {
if (!inputRef.current || !shouldResetFocusRef.current) {
return;
}
InteractionManager.runAfterInteractions(() => {
inputRef?.current?.focus();
const resetFocusRef = shouldResetFocusRef;
resetFocusRef.current = false;
});
},
};
export default inputFocusResetHandler;
import type {MutableRefObject} from 'react';
import type {TextInput} from 'react-native';
type InputFocusResetHandler = {
handleInputFocusReset: (inputRef: MutableRefObject<TextInput | null>, shouldResetFocusRef: React.MutableRefObject<boolean>) => void;
};
export default InputFocusResetHandler;
App/src/hooks/useResetComposerFocus.ts Lines 6 to 19 in 9412d21
export default function useResetComposerFocus(inputRef: MutableRefObject<TextInput | null>) {
const isFocused = useIsFocused();
const shouldResetFocusRef = useRef(false);
useEffect(() => {
if (!isFocused || !shouldResetFocusRef.current) {
return;
}
inputFocusResetHandler.handleInputFocusReset(inputRef, shouldResetFocusRef);
}, [isFocused, inputRef]);
return {isFocused, shouldResetFocusRef};
} POCScreen.Recording.2024-12-28.at.14.26.52.mp4Test branchWhat specific scenarios should we cover in automated tests to prevent reintroducing this issue in the future?I think we don’t need to test this because it is a UI bug. What alternative solutions did you explore? (Optional)Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job. |
I would love to help with the review if needed. |
📣 @shubham1206agra 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app! Offer link |
Also @shubham1206agra can you please review @huult 's thoughts and let us know what you think? @ikevin127 i'd be curious for your opinion too if you don't mind |
Oh shit. I didn't see the message. You can assign @brunovjk here if you want for C+ I am really sorry for this. |
Nope, I don't think time delays are a good solution. |
It’s simpler than checking the modal, RHP, or LHP to return early. If we miss one or the other, this issue will happen again. Anyway, I appreciate your selection. Thanks for your feedback! |
@Beamanator Definitely not for adding delay in this case as that doesn't fix the issue from the root, just patches the symptom. The root being that we focus the composer twice, which we shouldn't do in the first place. I agree with @shubham1206agra's review and comments on the other proposal. |
Hey team, no worries on my end about the review! I’m still available to help if needed but I’m confident @shubham1206agra will do a great job as well 🚀 🚀 Thank you @Beamanator ❤️ |
📣 @ikevin127 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app! Offer link |
Alright let's get goin' w/ @ikevin127 's proposal! Thanks all! |
Will open the PR sometime today (PST), thanks everyone! |
PR #54670 is now ready for review! 🚀 |
♻️ PR is and was ready for review for 3 days, still awaiting @shubham1206agra's review. |
@Beamanator Sorry, the pull request to fix this issue is already using the solution I proposed in my comment. So why was my proposal rejected by this comment, only for it to be implemented in the end? |
@Beamanator I think if we changed the solution, then my proposal should be reconsidered because I suggested it first 😢 |
@huult I know how it feels, but we are covering cases which are not defined in the issue itself, but we thought it would be a good idea to cover it rather than create a different ticket. But this case has happened a couple of times in the past, and no compensation will be provided to you since the solution was modified at a later stage. I wish you luck, and maybe I can find another issue for you to work on. See #54670 (comment) for more context on how we arrived at the solution. |
#54615 (comment) I mentioned a different case, but you still went with your selection. Hmm, I still feel it’s unfair. I think if you decided to change the solution, then you should have re-evaluated the proposals if they existed. |
|
The solution for this issue has been 🚀 deployed to production 🚀 in version 9.0.83-5 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue: If no regressions arise, payment will be issued on 2025-01-18. 🎊 For reference, here are some details about the assignees on this issue:
|
@ikevin127 / @shubham1206agra @sonialiap @ikevin127 / @shubham1206agra The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed. Please copy/paste the BugZero Checklist from here into a new comment on this GH and complete it. If you have the K2 extension, you can simply click: [this button] |
If you haven’t already, check out our contributing guidelines for onboarding and email contributors@expensify.com to request to join our Slack channel!
Version Number: 9.0.79-0
Reproducible in staging?: Yes
Reproducible in production?: No
If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Yes, reproducible on both
If this was caught during regression testing, add the test name, ID and link from TestRail: Exp
Email or phone of affected tester (no customers): applausetester+909608@applause.expensifail.com
Issue reported by: Applause Internal Team
Device used: iPhone 15 Pro Max / iOS 18.2
App Component: Chat Report View
Action Performed:
Expected Result:
Composer highlight will be persistant.
Actual Result:
Composer is highlighted, unhighlighted and then highlighted again.
Workaround:
Unknown
Platforms:
Screenshots/Videos
Bug6702848_1735292381914.ScreenRecording_12-27-2024_17-36-29_1.mp4
View all open jobs on GitHub
Upwork Automation - Do Not Edit
Issue Owner
Current Issue Owner: @sonialiapThe text was updated successfully, but these errors were encountered: