App
App copied to clipboard
[HOLD for payment 2024-12-17] [$250] Attachments - Attachment preview slides to the right with a delay when dismissed
If you havenβt already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!
Version Number: 9.0.65-3 Reproducible in staging?: Y Reproducible in production?: Y If this was caught on HybridApp, is this reproducible on New Expensify Standalone?: Y If this was caught during regression testing, add the test name, ID and link from TestRail: https://expensify.testrail.io/index.php?/tests/view/5249444 Issue reported by: Applause - Internal Team
Action Performed:
- Launch staging new.expensify Hybrid app and sign in
- Open 1:1 chat with variety of attachments sent
- Tap on attachment preview to open larger preview
- Tap < button on the left side of the preview to navigate back to the chat
- Repeat with a few other attachments
Expected Result:
Attachment preview can be dismissed without delay
Actual Result:
Attachment preview slides to the right with a delay when dismissed. Part of the current attachment followed by previously opened attachment can be seen for a couple of seconds on the right side of the screen
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
- [ ] Android: Standalone
- [ ] Android: HybridApp
- [ ] Android: mWeb Chrome
- [x] iOS: Standalone
- [x] iOS: HybridApp
- [ ] iOS: mWeb Safari
- [ ] MacOS: Chrome / Safari
- [ ] MacOS: Desktop
Screenshots/Videos
Add any screenshot/video evidence
https://github.com/user-attachments/assets/5495074b-2e9b-46ab-939a-0a589efd92b2
Upwork Automation - Do Not Edit
- Upwork Job URL: https://www.upwork.com/jobs/~021859724558833397121
- Upwork Job ID: 1859724558833397121
- Last Price Increase: 2024-11-21
- Automatic offers:
- huult | Contributor | 105065706
Issue Owner
Current Issue Owner: @trjExpensify
Triggered auto assignment to @trjExpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details. Please add this bug to a GH project, as outlined in the SO.
I can repro this:
https://github.com/user-attachments/assets/f45c17ce-e467-4150-af72-3ffd8c555af6
Job added to Upwork: https://www.upwork.com/jobs/~021859724558833397121
Triggered auto assignment to Contributor-plus team member for initial proposal review - @thesahindia (External)
Edited by proposal-police: This proposal was edited at 2024-11-22 07:32:34 UTC.
Proposal
Please re-state the problem that we are trying to solve in this issue.
Attachment preview slides to the right with a delay when dismissed
What is the root cause of that problem?
The modal dismissal was triggered before the attachment carousel animation completed. This caused a conflict between the animation lifecycle and modal dismissal, leading to visual inconsistencies.
https://github.com/Expensify/App/blob/5e2d95a6aaa5bd100c4c1e2e4b991fc05ba0e11d/src/pages/home/report/ReportAttachments.tsx#L54
https://github.com/Expensify/App/blob/f5e8d3e97489118e5daf53af043f35ba5935801a/src/components/Attachments/AttachmentCarousel/index.tsx#L294
This happens only on iOS native because its native modal animations run concurrently with Animated.FlatList, leading to conflicts. iOS enforces stricter rendering and animation synchronization, exposing timing issues.
What changes do you think we should make in order to solve the problem?
To resolve this issue, we must delay dismissing the modal until the animation of the attachment carousel is completed. This ensures that all active interactions, including animations and gestures, are finished before the modal is dismissed, avoiding conflicts between the animation lifecycle and modal dismissal. Something like this:
//src/pages/home/report/ReportAttachments.tsx#L55
<AttachmentModal
accountID={Number(accountID)}
type={type}
allowDownload
defaultOpen
report={report}
source={source}
onModalClose={() => {
+ InteractionManager.runAfterInteractions(() => {
+ requestAnimationFrame(() => {
Navigation.dismissModal();
// This enables Composer refocus when the attachments modal is closed by the browser navigation
ComposerFocusManager.setReadyToFocus();
+ });
+ });
}}
onCarouselAttachmentChange={onCarouselAttachmentChange}
shouldShowNotFoundPage={!isLoadingApp && type !== CONST.ATTACHMENT_TYPE.SEARCH && !report?.reportID}
isAuthTokenRequired={!!isAuthTokenRequired}
attachmentLink={attachmentLink ?? ''}
originalFileName={fileName ?? ''}
/>
Note: We can write this code specifically for iOS using Platform.OS === 'ios' or by creating an index.ios.ts file. We will discuss and implement this approach during the PR phase
POC
https://github.com/user-attachments/assets/d2b2b0ac-0f16-426c-ac0f-18f5bd359ac4
What alternative solutions did you explore? (Optional)
Proposal
Please re-state the problem that we are trying to solve in this issue.
Attachment preview slides to the right with a delay when dismissed. Part of the current attachment followed by previously opened attachment can be seen for a couple of seconds on the right side of the screen
What is the root cause of that problem?
When pressing back button:
https://github.com/Expensify/App/blob/056e8ee563b1136ba5749988d89723fad467c7fd/src/pages/home/report/ReportAttachments.tsx#L53-L57
AttachmentModal is closed before AttachmentCarousel finishes unmounting, which causes visual bug.
The same bug appears on TransactionReceiptPage as well:
https://github.com/user-attachments/assets/97ba5a7d-356b-4d13-b9f4-6f2cb14bba22
What changes do you think we should make in order to solve the problem?
Wrap onModalClose function with InteractionManager.runAfterInteractions:
https://github.com/Expensify/App/blob/056e8ee563b1136ba5749988d89723fad467c7fd/src/pages/home/report/ReportAttachments.tsx#L53-L57
onModalClose={() => {
InteractionManager.runAfterInteractions(() => {
Navigation.dismissModal();
// This enables Composer refocus when the attachments modal is closed by the browser navigation
ComposerFocusManager.setReadyToFocus();
});
}}
Apply the same for TransactionReceiptPage as well:
https://github.com/Expensify/App/blob/056e8ee563b1136ba5749988d89723fad467c7fd/src/pages/TransactionReceiptPage.tsx#L78
onModalClose={() => {
InteractionManager.runAfterInteractions(() => {
onModalClose();
});
}}
What alternative solutions did you explore? (Optional)
@huult's proposal is first but @daledah's proposal is also fixing another similar case. I will leave the decision to the engineer on this.
π π π C+ reviewed
Triggered auto assignment to @Beamanator, see https://stackoverflow.com/c/expensify/questions/7972 for more details.
@Beamanator whatcha' think of the proposal?
IMO since @huult had correct initial proposal, let's go with them π but since we also want to fix the bug on the other page, let's compensate @daledah a bit for their proposal / idea as well
Since we know that we need this fix on 2 pages, can @huult also check if we need to make this fix anywhere else?
π£ @huult π An offer has been automatically sent to your Upwork account for the Contributor role π Thanks for contributing to the Expensify app!
Offer link Upwork job Please accept the offer and leave a comment on the Github issue letting us know when we can expect a PR to be ready for review π§βπ» Keep in mind: Code of Conduct | Contributing π
@Beamanator Besides the two pages, Report Attachment and Transaction Receipt, we also have Report Avatar, Profile Avatar, and Workspace Avatar with similar cases. However, they have a file size limit, so I haven't observed this issue occurring with them. I will continue testing, and if any issues arise, I will include them in the pull request.
Amazing, thanks @huult ! π
β οΈ Looks like this issue was linked to a Deploy Blocker here
If you are the assigned CME please investigate whether the linked PR caused a regression and leave a comment with the results.
If a regression has occurred and you are the assigned CM follow the instructions here.
If this regression could have been avoided please consider also proposing a recommendation to the PR checklist so that we can avoid it in the future.
Reviewing label has been removed, please complete the "BugZero Checklist".
The solution for this issue has been :rocket: deployed to production :rocket: in version 9.0.73-8 and is now subject to a 7-day regression period :calendar:. Here is the list of pull requests that resolve this issue:
- https://github.com/Expensify/App/pull/53108
If no regressions arise, payment will be issued on 2024-12-17. :confetti_ball:
For reference, here are some details about the assignees on this issue:
- @huult requires payment automatic offer (Contributor)
- @thesahindia requires payment through NewDot Manual Requests
@thesahindia @trjExpensify @thesahindia 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]
π checklist time, please @thesahindia!
BugZero Checklist:
- [x] [Contributor] Classify the bug:
Bug classification
Source of bug:
- [x] 1a. Result of the original design (eg. a case wasn't considered)
- [ ] 1b. Mistake during implementation
- [ ] 1c. Backend bug
- [ ] 1z. Other:
Where bug was reported:
- [x] 2a. Reported on production (eg. bug slipped through the normal regression and PR testing process on staging)
- [ ] 2b. Reported on staging (eg. found during regression or PR testing)
- [ ] 2d. Reported on a PR
- [ ] 2z. Other:
Who reported the bug:
- [ ] 3a. Expensify user
- [ ] 3b. Expensify employee
- [ ] 3c. Contributor
- [x] 3d. QA
- [ ] 3z. Other:
-
[x] [Contributor] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake.
Link to comment: N/A
-
[x] [Contributor] If the regression was CRITICAL (e.g. interrupts a core flow) A discussion in #expensify-open-source has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner.
Link to discussion: N/A
-
[x] [Contributor] If it was decided to create a regression test for the bug, please propose the regression test steps using the template below to ensure the same bug will not reach production again.
Regression Test Proposal Template
-
[ ] [BugZero Assignee] Create a GH issue for creating/updating the regression test once above steps have been agreed upon.
Link to issue:
Regression Test Proposal
Test:
- Open any chat and send multiple images.
- Click on any attachment to open the attachment preview.
- Tap the "<" (back) button on the top-left corner to return to the chat.
- Repeat steps 2 and 3 for a few attachments.
- Verify that the attachment preview is dismissed smoothly without any delay.
Do we agree π or π
1a. Result of the original design (eg. a case wasn't considered)
Hm, really? You're saying since the inception of the attachment carousel this bug has existed?
The attachment closing animation on native has been a little janky from the beginning. Over time, we made many changes to the attachment preview modal to improve its smoothness. As the proposal states, "This happens only on iOS native because its native modal animations run concurrently with Animated.FlatList, leading to conflicts. iOS enforces stricter rendering and animation synchronization, exposing timing issues." Based on this, I think the option "1a. Result of the original design" is the most fitting for this case.
Hm okay, but I would suspect something in here would have been the cause.
Over time, we made many changes to the attachment preview modal to improve its smoothness.
Payment summary as follows:
- $250 to @huult for the fix (paid!)
- $250 to @thesahindia for the C+ review (go ahead request)
Settled up, closing!
@trjExpensify Hi, based on https://github.com/Expensify/App/issues/52937#issuecomment-2498867280, am I eligible for payment as well?
reopening to assess. π
Cool, so 1/4 the bounty. $62.5. @daledah what's your Upwork profile? (pro-tip, add it to your Slack profile).
@trjExpensify Hi here's my Upwork profile https://www.upwork.com/freelancers/~0138d999529f34d33f
@Beamanator, @trjExpensify, @huult, @thesahindia Whoops! This issue is 2 days overdue. Let's get this updated quick!
Not overdue!
@Beamanator, @trjExpensify, @huult, @thesahindia Huh... This is 4 days overdue. Who can take care of this?
@Beamanator, @trjExpensify, @huult, @thesahindia 8 days overdue is a lot. Should this be a Weekly issue? If so, feel free to change it!