Can't set Image extent to naturalExtent onLoad

[rickmcgeer]

Describe the bug I wanted to subclass Image in order to apply some styling and animation on top of it. Since I wanted the thing to rescale (and rescale submorphs with it) I set the thing to its naturalExtent on load, then sampled the window size and rescaled to fit. So the onLoad() code read:

onLoad() {
    this.imageUrl = 'https://matt.engagelively.com/assets/ITF/new_ibn_map_small.png'
   this.extent = this.naturalExtent;
}

As which point the screen froze, and this kept repeating in the console:

renderer.js:239 Error rendering morphs: TypeError: Cannot read properties of null (reading 'x')
    at Window.addExtentStyle (property-dom-mapping.js:137:26)
    at Window.styleProps (property-dom-mapping.js:47:21)
    at Window.defaultStyle (morphic-default.js:53:38)
    at Window.applyStylingToNode (morphic-default.js:26:38)
    at Renderer.Renderer_renderStylingChanges_ (renderer.js:561:31)
    at Renderer.Renderer_renderStep_ (renderer.js:285:22)
    at eval (renderer.js:237:24)

To Reproduce Steps to reproduce the behavior. Please make sure to let us know if your problem requires the loading of custom components,...

Screenshots

Setup Please delete non-applicable items!

• Windows

Version: Please paste the lively.next commit on which the problem occurred here (use the copy button of the Version Checker in the bottom left corner). a2f54f678bc0e2664d1d9589c4051010fdd87e53

[merryman]

Since you are passing an image to the image morph that has to be fetched via the internet, the morph can not possibly determine the natural extent synchronously, because it requires the entire file to be downloaded in order to do so. This is why you need to call await this.determineNaturalExtent() before working with the natural extent. This of course should be documented but is not, for reasons I will not repeat over and over again. With regards to the crash you observed, this happened after inserting an incorrect value into the extent property, which killed the renderer. @linusha I believe putting guard rails around some of the property values that can make the renderer crash like this could make the system a lot more stable.

[linusha]

@rickmcgeer to make things more clear: giving a local URL to load contents from within the lively folder will not resolve this. This will also be asynchronous, as we serve files via the lively server to the client in general. If this needs to be synchronously right now, you would probably need to encode the image in base64 inside of a JS module which can be synchronously evaluated.

However, I of course agree with @merryman that current situation is not great and we will improve it. That the renderer just crashes on you is unacceptable.

[rickmcgeer]

Yes, I figured this out. And the fix was easy, just hardcode the known extent of the asset. I'm pointing this out because others are sure to run into it...

On Tue, Jun 6, 2023 at 2:57 AM Linus Hagemann @.***> wrote:

@rickmcgeer https://github.com/rickmcgeer to make things more clear: giving a local URL to load contents from within the lively folder will not resolve this. This will also be asynchronous, as we serve files via the lively server to the client in general. If this needs to be synchronously right now, you would probably need to encode the image in base64 inside of a JS module which can be synchronously evaluated.

However, I of course agree with @merryman https://github.com/merryman that current situation is not great and we will improve it. That the renderer just crashes on you is unacceptable.

— Reply to this email directly, view it on GitHub https://github.com/LivelyKernel/lively.next/issues/881#issuecomment-1578330066, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAFAHAZ3YX3UPAA62YS464DXJ35KFANCNFSM6AAAAAAY32Z2EA . You are receiving this because you were mentioned.Message ID: @.***>

-- Rick McGeer @.*** +15103346004