[$250][HOLDnecolas/react-native-web#2709] Tab - When switching tabs, the Custom Profile Avatar shows delayed

[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.10-2
Reproducible in staging?: Y
Reproducible in production?: Y
If this was caught during regression testing, add the test name, ID and link from TestRail: N/A
Issue reported by: Applause - Internal Team

Issue found when executing PR #45663

Action Performed:

PreCondition: User has a custom avatar added to their profile.

1. Access staging.new.expensify.com
2. Sign into a valid account (Beta enabled)
3. Go to inbox tab
4. Go to Search tab
5. Go to Profile tab

Expected Result:

User expects the Avatar image to load instantly upon changing tabs

Actual Result:

The avatar image blinks a takes a couple of seconds to load

Workaround:

Unknown

Platforms:

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

• Android: Native
• Android: mWeb Chrome
• iOS: Native
• iOS: mWeb Safari
• MacOS: Chrome / Safari
• MacOS: Desktop

Screenshots/Videos

Add any screenshot/video evidence

Bug6548102_1721483392280.Avatar_shows_in_a_delayed_manner_when_switching_tabs_.mp4

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~01ec9d563c4ff0e779
• Upwork Job ID: 1816230532262348738
• Last Price Increase: 2024-08-07
• Automatic offers:
• dominictb | Contributor | 103496599

Issue Owner

Current Issue Owner: @s77rt

[melvin-bot]

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

[lanitochka17]

@strepanier03 FYI I haven't added the External label as I wasn't 100% sure about this issue. Please take a look and add the label if you agree it's a bug and can be handled by external contributors

[lanitochka17]

We think that this bug might be related to #vip-vsp

[dominictb]

Edited by proposal-police: This proposal was edited at 2024-08-08 03:11:24 UTC.

Proposal

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

The avatar image takes a couple of seconds to load

What is the root cause of that problem?

From here we can see that react-native-web's Image component won't show the image immediately if the image is not in the state LOADED, and in order to land in that state when the component mount, the image should be in the cache as dictated here

And in here, we never prefetch the avatar URL, hence the issue.

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

To solve this issue in react-native-web library, we can simply cache the image after load in here the same way in here, making sure that the image is in the LOADED state for subsequent access from the parent component

if(!ImageUriCache.has(uri)) {
   ImageUriCache.add(uri);
   ImageUriCache.remove(uri);
}

Some extra consideration: We should even add a param in load function as well as the respective prop in the parent components to control the caching behavior. For example, we might don't want to cache the image naively this way if it is loaded from local file or when it goes with defaultSource here. That can be ironed out later in the PR

OUTDATED solution

We should add a mechanism in the BaseImage.tsx component to prefetch the source, allowing the image to be displayed immediately in web: In here, add a call to prefetch the URI. We don't need to un-prefetch, or remove the URI from the cache as react-native-web only keep track of 256 URIs in the cache, and will remove least-accessed URI once the count has reached its limit

useEffect(() => {
        // shouldPrefetchUri is a new introduced prop, and we can control it from the parent component
        if(shouldPrefetchUri && props?.source?.['uri']) {
            // prefetch the image
            RNImage.prefetch(props.source?.['uri']);
        }
    }, [shouldPrefetchUri, props.source]);

In here, we can control that we only prefetch for non-authenticated source, but we can extend later for authenticated-required source.

What alternative solutions did you explore? (Optional)

Even more exact solution on web, suggested here https://stackoverflow.com/questions/2446740/post-loading-check-if-an-image-is-in-the-browser-cache/50111407#50111407, we can utilize this logic to check and set the initial state correctly. To achieve that, updateImageLoader.has function here

let globalImage = new window.Image(); // or we can initialize new image for every `ImageLoader.has` invocation.
....
has(uri) {
    globalImage.src = uri;
    let result = globalImage.complete;
    globalImage.src = '' // unset the src to prevent firing extra request
    return;
}

We can easily verify that this logic work on web by opening the devtools > network tab and try toggle disable cache option. If the cache is available, the image will load almost immediately from the second time.

[melvin-bot]

@strepanier03 Uh oh! This issue is overdue by 2 days. Don't forget to update your issues!

[strepanier03]

Working on this now.

[strepanier03]

Repro'd all good here.

[melvin-bot]

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

[melvin-bot]

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

[s77rt]

@dominictb

in order to land in that state when the component mount, the image should be in the cache

Isn't the image being cached?

[dominictb]

@s77rt please check this logic, then you will see that by default the image URL is not in the cache, as nowhere in the code did we call Image.prefetch function

[s77rt]

@dominictb After an image is loaded the first time it should be cached. Next time you render the same image it should load from the cache. Why this is not the case here?

[dominictb]

@s77rt it is true that once the image is loaded the first time, it is in the browser cache. But that doesn't mean this condition is true, and that means, the image is not shown as implemented here

So, to show the image immediately, we need to make this condition to be true, i.e: Call Image.prefetch for the image URI.

[s77rt]

@dominictb Sounds to me like a bug in RNW. If we overwrite the initial state to be LOADED. Will the image load correctly on tab switch?

[dominictb]

If we overwrite the initial state to be LOADED. Will the image load correctly on tab switch?

@s77rt you can, but it might defeat the use case where we want to use image placeholder (check this out) while the image is loading

[s77rt]

@dominictb Will the image load correctly (from cache) in that case? (regardless of the placeholder)

[dominictb]

Will the image load correctly (from cache) in that case? (regardless of the placeholder)

@s77rt yes.

[s77rt]

@dominictb In that case the bug should be fixed at RNW level

[dominictb]

@s77rt proposal updated with fix in react-native-web lib itself.

[s77rt]

@dominictb Adding the image uri to the cache entries makes sense to me but a better solution is to make use of the browser cache, that is to modify the ImageUriCache.has method to check if a uri is already cached. Can you look into that?

[dominictb]

@s77rt necolas/react-native-web#2709 upstream PR and linked issue are up

[melvin-bot]

@strepanier03 @s77rt @stitesExpensify @dominictb this issue is now 4 weeks old, please consider:

• Finding a contributor to fix the bug
• Closing the issue if BZ has been unable to add the issue to a VIP or Wave project
• If you have any questions, don't hesitate to start a discussion in #expensify-open-source

Thanks!

[s77rt]

Not overdue. Waiting on RNW PR feedback

[melvin-bot]

@strepanier03, @s77rt, @stitesExpensify, @dominictb Whoops! This issue is 2 days overdue. Let's get this updated quick!

[s77rt]

Same ^

[s77rt]

@stitesExpensify Let's make this Weekly and hold on necolas/react-native-web#2709

[melvin-bot]

This issue has not been updated in over 15 days. @strepanier03, @s77rt, @stitesExpensify, @dominictb eroding to Monthly issue.

P.S. Is everyone reading this sure this is really a near-term priority? Be brave: if you disagree, go ahead and close it out. If someone disagrees, they'll reopen it, and if they don't: one less thing to do!

[s77rt]

Still on hold

[strepanier03]

Put this in #quality.

[s77rt]

@dominictb Seems like the upstream PR needs your attention. Please provide a reproducer for the repo maintainers to test

[dominictb]

@s77rt thanks, I'll check and update the upstream PR as soon as possible

[dominictb]

@s77rt this is a little bit weird, I couldn't reproduce the original bug in react-native-web. I checked for both case: when enable cache and when disable cache. I believe the original bug, I believe, is partly due to #47041, which has already solved.

So what should be the next step here?

[s77rt]

@dominictb Is the bug no longer reproducible? Did you try with a custom avatar?

[dominictb]

@s77rt the original bug is no longer reproducible after #47041 is fixed. I have tried with custom avatar to confirm this.

Nonetheless, the analysis in my proposal is correct, I figured a way to make it reproducible in the upstream but not so sure the improvement we introduced is significant enough. I'll make an update in the upstream PR and see what the author's final decision is.

[dominictb]

@s77rt after checking this, the correct root cause and fix of this issue should already covered by #47041, and I personally couldn't reproduce this in the upstream repo either. Even though necolas/react-native-web#2708 (comment) is correct and the upstream PR is a nice improvement, it might break the SSR support of the Image component, hence I don't think the upstream change is needed anymore.

[s77rt]

@dominictb If we have nothing to fix then let's do nothing