Image onLoad event (ImageLoadEvent) object is empty in Chrome version 109.0.5414.87 on M1 Mac

[musnit]

Is there an existing issue for this?

• I have searched the existing issues

Describe the issue

In the latest version of Chrome on an M1 Mac (Version 109.0.5414.87 (Official Build) (arm64)), the Image onLoad event no longer contains all expected fields - for example, path and target are not available fields as expected in https://reactnative.dev/docs/image#imageloadevent.

https://codesandbox.io/s/priceless-feather-jk2mm7?file=/src/App.js:0-596

Expected behavior

When logging the event, as in the example above, I expect the path and target fields to be on the nativeEvent object

Steps to reproduce

See above sandbox

Test case

https://codesandbox.io/s/priceless-feather-jk2mm7?file=/src/App.js:0-596

Additional comments

No response

[kidroca]

AFAIK onload never matched the RN Image Load event

And it shouldn't contain path or target, but source with uri, width and height

[kidroca]

I'm trying to make onload match the react-native Image interface here: 80ee858

[musnit]

AFAIK onload never matched the RN Image Load event

And it shouldn't contain path or target, but source with uri, width and height

I believe it did include a path/target or some reference the DOM node that caused the event

[kidroca]

I believe it did include a path/target or some reference the DOM node that caused the event

Yes a path did exist at some point, and it was an array like [img] where img was the html element
It seems it was recently deprecated: https://chromestatus.com/feature/5726124632965120
This is not a bug in react-native-web or related to M1 / arm64

Event.path is a non-standard API that returns the event's path, which is an array of the objects on which listeners will be invoked. It is supported by Blink only, causing web compatibility issues

If you load an image the way react-native-web does, target would be null

var img = new Image();
img.onload = e => {
    console.log(e)
    window.myEvent = e;
};

img.src = 'https://images.unsplash.com/photo-1481595357459-84468f6eeaac?dpr=1&auto=format&fit=crop&w=376&h=251&q=60&cs=tinysrgb';

myEvent.target // null
'path' in myEvent // false
'path' in Event.prototype // false

---

A target exposing the html element can be exposed from onLoad, but I think most people that need it would just pass a ref as it is the most common way to work with underlying elements

const img = useRef();
return <Image ref={img} />

[musnit]

Ah thanks for digging in and finding the Chrome change! and yeah, ref fix seems more appropriate, thanks!

[xilin]

Hi @kidroca @musnit , img ref will be the parent view, it seems quite hacky to find img element inside the view then get the img properties. Can we consider to use the patch 80ee858? Or is there any better way to get img's width/height ?

[kidroca]

Hi, @xilin

Hi @kidroca @musnit , img ref will be the parent view, it seems quite hacky to find img element inside the view then get the img properties. Can we consider to use the patch 80ee858? Or is there any better way to get img's width/height ?

You can borrow this patch https://github.com/Expensify/App/blob/b7436524af53a84f5471bc3af14390632500882e/patches/react-native-web%2B0.20.0%2B003%2Bimage-header-support.patch

and apply it using npx patch-package

It's based on this Pull Request: #2442

Then the onLoad prop would be called with image dimensions

---

The hacky solution with the ref might be less taxing overall, especially if you're not managing other patches with patch-package

[xilin]

Hi, @xilin

Hi @kidroca @musnit , img ref will be the parent view, it seems quite hacky to find img element inside the view then get the img properties. Can we consider to use the patch 80ee858? Or is there any better way to get img's width/height ?

You can borrow this patch https://github.com/Expensify/App/blob/b7436524af53a84f5471bc3af14390632500882e/patches/react-native-web%2B0.20.0%2B003%2Bimage-header-support.patch

and apply it using npx patch-package

It's based on this Pull Request: #2442

Then the onLoad prop would be called with image dimensions

The hacky solution with the ref might be less taxing overall, especially if you're not managing other patches with patch-package

Thanks for sharing! Yeah we've used patch-package and adding a patch works for us. But still hope we can merge your PR soon to have build in support.