Image component of react native does not fire onLoadStart, onLoad, onLoadEnd in the correct order when picking the image using react-native-image-crop-picker

[fab-nikhil]

Description

I am currently on React Native 0.81.4 with new architecture enabled.
Whenever I pick the image using the react-native-image-crop-picker, the order of onLoad related events changes -
What I am getting -
onLoad -> onLoadEnd -> onLoadStart

What I expect -
onLoadStart -> onLoad -> onLoadEnd

When I use a url to provide image, it works fine. but If I pick the image using the Image crop picker, the order of events being fired changes.

Steps to reproduce

1. Create a new project using the react-native-community/cli
2. Add 'react-native-image-crop-picker' and update the Info.plist file
3. run pod install and then npm run ios
4. Add 'Button' in the component to open the Image Picker and select a image.
5. Pass the 'uri' provided by the Image Picker to Image component provided by react native.

React Native Version

0.81.4

Affected Platforms

Runtime - iOS

Output of npx @react-native-community/cli info

System:
  OS: macOS 15.3.1
  CPU: (12) arm64 Apple M4 Pro
  Memory: 138.42 MB / 24.00 GB
  Shell:
    version: "5.9"
    path: /bin/zsh
Binaries:
  Node:
    version: 22.19.0
    path: /Users/cs03466/.nvm/versions/node/v22.19.0/bin/node
  Yarn:
    version: 1.22.22
    path: /Users/cs03466/.nvm/versions/node/v22.19.0/bin/yarn
  npm:
    version: 10.9.3
    path: /Users/cs03466/.nvm/versions/node/v22.19.0/bin/npm
  Watchman:
    version: 2025.09.08.00
    path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.16.2
    path: /Users/cs03466/.rbenv/shims/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 24.5
      - iOS 18.5
      - macOS 15.5
      - tvOS 18.5
      - visionOS 2.5
      - watchOS 11.5
  Android SDK: Not Found
IDEs:
  Android Studio: 2025.1 AI-251.26094.121.2513.14007798
  Xcode:
    version: 16.4/16F6
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 17.0.16
    path: /usr/bin/javac
  Ruby:
    version: 3.4.5
    path: /Users/cs03466/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 20.0.0
    wanted: 20.0.0
  react:
    installed: 19.1.0
    wanted: 19.1.0
  react-native:
    installed: 0.81.4
    wanted: 0.81.4
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true

Stacktrace or Logs

console.js:661 Running "ReproducerProject" with {"rootTag":11,"initialProps":null,"fabric":true}
console.js:661 onLoadStart fired
console.js:661 onLoad fired
console.js:661 onLoadEnd fired
console.js:661 Image selected: /Users/cs03466/Library/Developer/CoreSimulator/Devices/EEA57008-1B76-416C-849C-3D362C6527B7/data/Containers/Data/Application/FFEF6540-901F-4026-95FB-6FEF1FB1843F/tmp/react-native-image-crop-picker/E7351B54-A36A-4767-B81E-B8BA431A509D.jpg
console.js:661 onLoad fired
console.js:661 onLoadEnd fired
console.js:661 onLoadStart fired

MANDATORY Reproducer

https://github.com/fab-nikhil/image-component-issue-reproducer

Screenshots and Videos

No response

[fab-nikhil]

This issue is intermittent. If you try 10 times, you might face this at least 5-6 times.
I also tried upgrading to React Native 0.82.0 and the issue still persists

[StrauneanuDimitri]

I've never had this issue with old versions of React Native (0.79.2 and older) and the old architecture. Just last week I have upgraded React Native to 0.82.0 and switched to the new architecture for my app and then this issue started to reproduce every time I run the app.

[kevalkikani180]

{"id":"25793","variant":"standard","title":"Short Fix Summary for Image Load Event Order Issue"}

Possible Cause

Under the new architecture (Fabric), local file URIs from react-native-image-crop-picker sometimes trigger onLoad and onLoadEnd before onLoadStart on iOS. This doesn’t happen with remote URLs.

Workarounds

1. Add file:// prefix** to the picked image path:
   js
   const uri = image.path.startsWith('file://') ? image.path : file://${image.path};

2.Delay render slightly:**
js
setTimeout(() => setSelectedImage(image.path), 100);

3.Debug:** Disable Fabric (RCT_NEW_ARCH_ENABLED=0) to confirm it’s Fabric-related.

Note

Likely a Fabric image event ordering issue in iOS (RCTImageView). Should ensure onLoadStart fires before onLoad for local URIs.

[haeniya]

Same issue here but unrelated to the image picker. onLoadEnd is fired before onLoadStart on iOS (probably when image is cached). As a workaround I had to do this for now:

<Image
  onLoadStart={() => {
    setLoading(true);
  }}
  onLoadEnd={() => {
    setTimeout(() => {
      setLoading(false);
    }, 200);
  }}
  source={{ uri: item.uri }}
  style={styles.image}
/>

[cveklica]

same for any other image, and not consistent. I tried both Image from react-native and FastImage.
I am on RN 0.83.2

[SatyamBansal]

This is not specific to react-native-image-crop-picker — it is a Fabric image-event
ordering bug, and it reproduces with no picker and no library, on 0.87.1. Root cause
and a minimal reproducer below. (Retitle/relabel probably warranted; the Component: Picker
label is sending people the wrong way, and two comments above already report it with
plain images.)

Trigger

onLoadStart arrives last whenever the new image request completes before the mount
transaction applies. The deterministic way to hit that is a source change on an
already-mounted <Image> where the new source resolves without I/O (a data: URI):
layout creates the ImageRequest, the decode finishes on a background queue in
microseconds, and the mount transaction applies a frame later.

Notably not sufficient on their own — both measured: Image.prefetch then mount, and
remounting the same URI. On a fresh mount the request is still Loading when the view
subscribes, because RCTImageManager.requestImage dispatches the fetch to a background
queue after returning. That is why a picked local file, or a cached image behind a
navigation transition, looks intermittent — the window has to be wide enough.

Mechanism

1. RCTImageComponentView.mm updateState:oldState: subscribes before it announces the
   start — [self _setStateAndResubscribeImageResponseObserver:newImageState] (0.86.0 L87 /
   main L97) then ...onLoadStart() (L95 / L105).
2. ImageResponseObserverCoordinator.cpp addObserver does not queue a finished request, it
   replays it synchronously: case Completed: → observer->didReceiveImage(...) (L37),
   and case Failed: → didReceiveFailure(...) (L43).
3. RCTImageResponseObserverProxy.mm forwards via RCTExecuteOnMainQueue, which in
   RCTUtils.mm is if (RCTIsMainQueue()) { block(); } — inline, and mounting is on the
   main thread.
4. So didReceiveImage: emits onLoad + onLoadEnd (L139–140 / L149–150) while still inside
   step 1, and onLoadStart follows at step 1's caller.

Old architecture cannot invert: RCTImageView.mm reloadImage emits _onLoadStart (L309)
before calling loadImageWithURLRequest: (L345). Android cannot either: ReactImageView.kt
binds onLoadStart to Fresco's onSubmit (L152) and onLoad/onLoadEnd to onFinalImageSet
(L161), and submission always precedes delivery. (I reasoned these two from source but did not
run them, so treat them as unverified controls.)

I re-fetched all of the above from main today — unchanged. Still present.

Measured

RN 0.87.1, iPhone 17 Pro simulator, iOS 26.3, New Arch, debug. Sequence number from
++ref.current evaluated inside each callback; performance.now() timestamps.

First mount, every column correct:

#2  912747278.58  onLoadStart E
#6  912747278.66  onLoad      E
#7  912747278.67  onLoadEnd   E

After swapping that same mounted <Image>'s source, twice in a row:

#1  912798714.91  onLoad      E
#2  912798715.06  onLoadEnd   E
#3  912798715.08  onLoadStart E

All within 0.2 ms, one mount transaction — not an async race.

Impact

Anything that shows a spinner on onLoadStart and hides it on onLoadEnd is stuck on
forever, because the event that turns it on arrives after the one that would turn it off. We
hit it in an image carousel that pages by swapping one <Image>'s source: slide 1 rendered,
every later slide sat under a permanent spinner over a fully-decoded image. The setTimeout
workaround above is the only thing that helps without patching, and it is a guess at a
duration.

Suggested fix

Hoist the onLoadStart() emission above the
_setStateAndResubscribeImageResponseObserver: call in updateState:oldState:, so the
subscription — and any synchronous replay of an already-finished response — happens after the
start event has been announced. One-line move; happy to open the PR if a maintainer confirms
that is the shape they want.

Reproducer

https://github.com/SatyamBansal/rn-repro-image-onloadstart-order

Built from the community template; only ReproducerApp/App.tsx differs. Launch, read the
log (all columns correct), press Swap E source, read it again.

npx @react-native-community/cli info

path: /opt/homebrew/bin/watchman
Managers:
  CocoaPods:
    version: 1.16.2
    path: /Users/<user>/.rbenv/shims/pod
SDKs:
  iOS SDK:
    Platforms:
      - DriverKit 25.2
      - iOS 26.2
      - macOS 26.2
      - tvOS 26.2
      - visionOS 26.2
      - watchOS 26.2
  Android SDK:
    API Levels:
      - "35"
      - "36"
      - "36"
    Build Tools:
      - 35.0.0
      - 36.0.0
      - 36.1.0
    System Images:
      - android-36.1 | Google APIs ARM 64 v8a
      - android-36.1 | Google Play ARM 64 v8a
      - android-36.1 | 16 KB Page Size Google APIs ARM 64 v8a
    Android NDK: Not Found
IDEs:
  Android Studio: 2025.3 AI-253.30387.90.2532.14935130
  Xcode:
    version: 26.3/17C529
    path: /usr/bin/xcodebuild
Languages:
  Java:
    version: 21.0.10
    path: /usr/bin/javac
  Ruby:
    version: 3.3.0
    path: /Users/<user>/.rbenv/shims/ruby
npmPackages:
  "@react-native-community/cli":
    installed: 20.2.0
    wanted: 20.2.0
  react:
    installed: 19.2.3
    wanted: 19.2.3
  react-native:
    installed: 0.87.1
    wanted: 0.87.1
  react-native-macos: Not Found
npmGlobalPackages:
  "*react-native*": Not Found
Android:
  hermesEnabled: true
  newArchEnabled: true
iOS:
  hermesEnabled: true
  newArchEnabled: true