fix: defer initial size measurement to ResizeObserver

[nidhiyashwanth]

Fixes #143

Problem

setupSizeChangedNotifications() was measuring DOM size immediately after connect(), before async content (maps, data fetches) could load. This caused widgets to report their loading spinner height (~110px) instead of final content height, resulting in clipped content.

Reproduction Flow

1. Widget connects and displays loading spinner
2. SDK immediately measures height (~110px for spinner only)
3. Host resizes iframe to match reported dimensions
4. Async content loads but container remains constrained
5. Content renders clipped due to insufficient space

Solution

Remove the immediate sendBodySizeChanged() call and rely purely on ResizeObserver, which fires when content actually renders and changes size.

Before (line 982)

sendBodySizeChanged();  // Immediate measurement - PROBLEM

const resizeObserver = new ResizeObserver(sendBodySizeChanged);

After

// ResizeObserver will fire for initial layout and all subsequent changes
const resizeObserver = new ResizeObserver(sendBodySizeChanged);

Why This Works

1. ResizeObserver already monitors document.documentElement and document.body
2. It fires on initial render AND subsequent size changes
3. Async content triggers ResizeObserver when it loads
4. Minimal code change (1 line removed)
5. Fully backward compatible

Testing

• Unit tests pass (npm test)
• E2E tests pass (npm run test:e2e)
• Prettier formatting passes

[liady]

@nidhiyashwanth thanks! Though even now in the described scenario the sendBodySizeChanged should be called again with correct values - once the async content is loaded - since the ResizeObserver will trigger it, right?

[nidhiyashwanth]

@liady Yup, ResizeObserver should fire when async content loads. However, ResizeObserver detects DOM element dimension changes, not content changes inside elements.

In the map widget case: the map renders tiles into an existing <div> whose computed size is already constrained by the 110px iframe. The container's DOM dimensions don't change, so ResizeObserver never fires.

By removing the immediate call, we let ResizeObserver's first measurement happen when the app renders its intended layout, rather than capturing an empty/loading state that locks in a tiny iframe.

[liady]

@nidhiyashwanth got it. There might be another issue at play here - why is the div in that scenario constrained by the iframe size (if it needs to be flexible for the map to load into), and why doesn't it happen if we remove the initial size message? The iframe has an initial size anyway.

[nidhiyashwanth]

@liady The iframe does have an initial CSS size (e.g., 600px in basic-host). The difference is timing:

With immediate call: iframe shrinks to 110px before the map loads → map initializes in tiny container

Without immediate call: iframe stays at CSS default (600px) while map loads → map initializes with room to breathe → ResizeObserver fires with actual content size → host adjusts

So it's about preserving the initial "breathing room" until content is ready, rather than prematurely shrinking the container.

[liady]

@nidhiyashwanth exactly - so it depends on the host to provide a sensible initial size in the first place, right? Perhaps the map's div needs to have a minHeight?

I'm just noting that if it depends on timing then it's brittle (what if the map's script loads itself only after a 1s timeout, for example? It will still break).

[nidhiyashwanth]

@liady understood. Do you have any other approach in mind? A few I could think of are:

• Add option like autoResize: 'manual' where app calls app.startSizeNotifications() when ready

• Apps with async content should use minHeight on containers

Do you think would any of these work better, or do you have something else in mind?