[$250] Android - Chat - User lands on previous attachment when sending image and opening preview

[lanitochka17]

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.60-0
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/5204055&group_by=cases:section_id&group_order=asc&group_id=292107
Issue reported by: Applause - Internal Team

Action Performed:

1. Open the Expensify app
2. Open any chat that contains at least an image or video attachment on it
3. Tap on the "+" button and select "Add Attachment"
4. Tap on "Choose File" and select any image to upload
5. Tap on "Send"
6. Once redirected to chat, tap quickly on the just sent image
7. Verify that the user lands on the image preview and that it loads correctly

Expected Result:

Preview of the just sent image should load correctly and the user should remain on it when opened

Actual Result:

When sending an image to a chat that already contains an image or video attachment, and opening the preview quickly when it was just sent, the user lands on a previous attachment and not in the one that was selected

Workaround:

Unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android: Standalone
• Android: HybridApp
• Android: mWeb Chrome
• iOS: Standalone
• iOS: HybridApp
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6662715_1731428003671.Prev_Attachment.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~021856559033364524387
• Upwork Job ID: 1856559033364524387
• Last Price Increase: 2024-11-20
• Automatic offers:
• nkdengineer | Contributor | 105065079

Issue Owner

Current Issue Owner: @akinwale

[melvin-bot]

Triggered auto assignment to @greg-schroeder (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.

[melvin-bot]

Job added to Upwork: https://www.upwork.com/jobs/~021856559033364524387

[melvin-bot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @akinwale (External)

[nkdengineer]

Proposal

Please re-state the problem that we are trying to solve in this issue.

When sending an image to a chat that already contains an image or video attachment, and opening the preview quickly when it was just sent, the user lands on a previous attachment and not in the one that was selected

What is the root cause of that problem?

When we add an attachment and click to open attachment quickly, the item.souce is changed from the local source to the Expensify source after the API is complete

App/src/components/Attachments/AttachmentCarousel/index.native.tsx

Line 143 in c24d217

items={attachments}

This causes the key of the item to be changed and then onPageSelected is called unexpectedly with the position is the previous attachment

App/src/components/Attachments/AttachmentCarousel/Pager/index.tsx

Lines 89 to 94 in c24d217

	const extractItemKey = useCallback(
	(item: Attachment, index: number) =>
	typeof item.source === 'string' || typeof item.source === 'number' ? `source-${item.source}` : `reportActionID-${item.reportActionID}` ?? `index-${index}`,
	[],
	);

App/src/components/Attachments/AttachmentCarousel/Pager/index.tsx

Line 129 in c24d217

key={extractItemKey(item, index)}

What changes do you think we should make in order to solve the problem?

Since item.source can be changed, we should return the consistent key as reportActionID-${item.reportActionID} or index-{index}

const extractItemKey = useCallback((item: Attachment, index: number) => `reportActionID-${item.reportActionID}`, []);

or

const extractItemKey = useCallback((item: Attachment, index: number) => `index-{index}`, []);

App/src/components/Attachments/AttachmentCarousel/Pager/index.tsx

Lines 89 to 94 in c24d217

	const extractItemKey = useCallback(
	(item: Attachment, index: number) =>
	typeof item.source === 'string' || typeof item.source === 'number' ? `source-${item.source}` : `reportActionID-${item.reportActionID}` ?? `index-${index}`,
	[],
	);

What alternative solutions did you explore? (Optional)

Result

Screen.Recording.2024-11-13.at.14.35.58.mov

[huult]

Proposal

Please re-state the problem that we are trying to solve in this issue.

User lands on previous attachment when sending image and opening preview

What is the root cause of that problem?

We send the attachment and open it immediately, so the source will initially be a local path. After the upload is finished, the source changes to the expensify path. This triggers the list to re-render because we used it for the keyExtractor.

App/src/components/Attachments/AttachmentCarousel/index.tsx

Lines 182 to 186 in 5ecd45e

	const extractItemKey = useCallback(
	(item: Attachment, index: number) =>
	typeof item.source === 'string' || typeof item.source === 'number' ? `source-${item.source}` : `reportActionID-${item.reportActionID}` ?? `index-${index}`,
	[],
	);

After the list re-renders, the activePage is lost and reset once the re-render is complete. As a result, we will see the attachment from the previous ticket

What changes do you think we should make in order to solve the problem?

We can't change the source used as the key because it's meant to prevent unnecessary re-renders when we have multiple sources with the same path.

To resolve this issue, we should store the activePage before the re-render and restore it after the re-render is complete.

1. Create two variables: keys to store the keys of the list and activePageBeforeChangedKey to store activePage before re-rendering.

// src/components/Attachments/AttachmentCarousel/index.native.tsx#L31
+    const [keys, setKeys] = useState([]);
+    const [activePageBeforeChangedKey, setActivePageBeforeChangedKey] = useState();

2. Add this block to handle storing the activePage. This only happens if the attachment source is a local file, so we need to check if it is local and key changes.

// src/components/Attachments/AttachmentCarousel/index.native.tsx#L111
+    const extractItemKey = useCallback((item: Attachment, index: number) => {
+        return typeof item.source === 'string' || typeof item.source === 'number' ? `source-${item.source}` : `reportActionID-${item.reportActionID}` ?? `index-${index}`;
+    }, []);

+    useEffect(() => {
+        const currentKeys = attachments.map((item, index) => extractItemKey(item, index));
+        const isIncludedLocalFile = attachments.some((item) => FileUtils.isLocalFile(item.source));

+        if (JSON.stringify(currentKeys) !== JSON.stringify(keys) && isIncludedLocalFile) {
+            console.log('Keys have changed');
+            setKeys(currentKeys);
+            setActivePageBeforeChangedKey(page);
+        }
+    }, [activePageBeforeChangedKey, attachments, extractItemKey, keys, page]);

3. After the page re-renders, restore the key and reset activePageBeforeChangedKey

+    useEffect(() => {
+        if (page === activePageBeforeChangedKey || activePageBeforeChangedKey === undefined) {
+            return;
+        }

+        setPage(activePageBeforeChangedKey);
+        if (activePageBeforeChangedKey) {
+            pagerRef.current?.setPage(activePageBeforeChangedKey);
+        }
+        setActivePageBeforeChangedKey(undefined);
+    }, [activePageBeforeChangedKey, page]);

Note: We can still apply this logic if the web platform is also affected

Test branch

POC

Screen.Recording.2024-11-14.at.00.36.13.mp4

[greg-schroeder]

Proposal review next up!

[akinwale]

We can move forward with @nkdengineer's proposal here.

🎀👀🎀 C+ reviewed.

[melvin-bot]

Triggered auto assignment to @srikarparsi, see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[huult]

@akinwale Can you take a look at my proposal? If we don't use source as the key, then in case of the same source, it will re-render.

[melvin-bot]

@akinwale, @greg-schroeder, @srikarparsi Huh... This is 4 days overdue. Who can take care of this?

[srikarparsi]

Hey @akinwale, have you had a chance to look at @huult's comment?

[akinwale]

@akinwale Can you take a look at my proposal? If we don't use source as the key, then in case of the same source, it will re-render.

@huult Could you post a video showing this re-render behaviour? I can't seem to reproduce on my end.

[nkdengineer]

If we don't use source as the key, then in case of the same source, it will re-render.

The source can not be the same and using a stable key doesn't cause any problem.

[melvin-bot]

📣 It's been a week! Do we have any satisfactory proposals yet? Do we need to adjust the bounty for this issue? 💸

[huult]

@akinwale I tested the case and pasted it twice. This is a case with the same source, but I saw that it is handled elsewhere. So, I think my comment is outdated. Thanks.

[nkdengineer]

@srikarparsi We have no concerns now. We're good to move this forward.

[melvin-bot]

@akinwale, @greg-schroeder, @srikarparsi Eep! 4 days overdue now. Issues have feelings too...

[nkdengineer]

@srikarparsi Bump on above.

[srikarparsi]

Sounds good, thanks

[melvin-bot]

📣 @nkdengineer 🎉 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 📖

[melvin-bot]

@akinwale @greg-schroeder @srikarparsi @nkdengineer this issue was created 2 weeks ago. Are we close to approving a proposal? If not, what's blocking us from getting this issue assigned? Don't hesitate to create a thread in #expensify-open-source to align faster in real time. Thanks!

[mvtglobally]

Issue not reproducible during KI retests. (First week)