hui-iframe-card / panel_iframe should get same height fix as #29681 — iframe collapses on iOS Companion

[dalvonc]

Checklist

• I have updated to the latest available Home Assistant version.
• I have cleared the cache of my browser.
• I have tried a different browser to see if it is related to my browser.
• I have tried reproducing the issue in safe mode to rule out problems with unsupported custom resources.

Describe the issue you are experiencing

hui-iframe-card and panel_iframe show the same iframe height-collapse symptom that was fixed for ha-panel-custom in PR #29681, but the fix was not applied to these components.

Symptom: After multiple Home Assistant iOS Companion app open/close cycles, the iframe collapses to ~1/3 of screen height. The top portion (header + first card) renders correctly. The bottom portion shows an unusable empty/grey area until the HA tab bar.

This is the same visual symptom reported in #28868 ("unusable grey margin at the bottom"), which was closed by #29681 — but #29681 only modified src/panels/custom/ha-panel-custom.ts.

Direct iOS Safari access works fine. Android HA Companion works fine. ONLY iOS HA Companion exhibits the bug.

Related:

• hass-subpage in ha-panel-custom has incorrect height on mobile #28868 (same symptom, fixed for custom panel only)
• Fix custom panel size #29681 (the fix, only applied to ha-panel-custom.ts)
• iOS Companion App goes permanently blank (WKWebView destroyed) when toggling devices — No activeURL available #29118 (related iOS Companion WKWebView lifecycle bug, still open)
• WebKit Bug #170595 (underlying innerHeight cache issue, Apple unfixed since 2017)

Describe the behavior you expected

Apply the same height: 100vh; height: 100dvh; dual-fallback fix from #29681 to:

• src/panels/iframe/ha-panel-iframe.ts (legacy panel_iframe YAML)
• src/panels/lovelace/cards/hui-iframe-card.ts (used by Webpage Dashboard since 2024.4)

The iframe should fill 100dvh consistently on iOS Companion regardless of WKWebView lifecycle events. Many users embed React/Vue SPAs via panel_iframe (Frigate before Ingress, custom dashboards, third-party apps) and should get the same baseline as custom panel users.

Steps to reproduce the issue

1. Configure a panel_iframe via YAML pointing to any React SPA, or add a webpage card via Webpage Dashboard
   Example:
   panel_iframe:
   myapp:
   title: "My App"
   url: "https://my-react-spa.example.com/"

2. On iPhone (iOS 26) with HA iOS Companion app installed:

   • Open the iframe panel
   • Tap home button to background HA app
   • Foreground HA app from app switcher
   • Repeat background/foreground 10-20 times rapidly

3. At some point iframe shrinks to ~1/3 height. Top of SPA renders correctly but bottom is empty grey/black area.

4. Verify it does NOT happen:

   • Direct iOS Safari to same URL: works fine
   • Android HA Companion: works fine
   • Desktop browser: works fine

Tested with HA Core 2026.4.2, Frontend 20260325.7, HA Companion iOS latest, iPhone iOS 26.

What version of Home Assistant Core has the issue?

2026.4.2 (Container) — Frontend 20260325.7

What was the last working version of Home Assistant Core?

No response

In which browser are you experiencing the issue?

No response

Which operating system are you using to run this browser?

No response

State of relevant entities

Problem-relevant frontend configuration

JavaScript errors shown in your browser console/inspector

Additional information

No response

[shrey239]

The issue appears to be caused by stale/cached viewport height values in iOS WKWebView during repeated background/foreground lifecycle events inside the Home Assistant iOS Companion app.

A similar issue was previously fixed for ha-panel-custom in PR #29681 by applying dual viewport height fallback styling:

height: 100vh;
height: 100dvh;

However, the same fix was not applied to:

src/panels/iframe/ha-panel-iframe.ts
src/panels/lovelace/cards/hui-iframe-card.ts
Suggested Fix

Apply the same viewport sizing strategy used in ha-panel-custom.ts to the iframe container/components used by:

panel_iframe
hui-iframe-card

This should ensure the iframe consistently reflows to the correct dynamic viewport height after WKWebView lifecycle changes on iOS.

[dalvonc]

Thanks @shrey239. Update from our side — we already have all three layers of this CSS fix running and the bug still reproduces:

1. card-mod on hui-iframe-card with height: 100vh !important; height: 100dvh !important on both ha-card and iframe selectors (essentially the PR Fix custom panel size #29681 fix applied from the dashboard side)
2. HA-side iframe-fix.js listening for postMessage from the iframe child and flipping iframe.style.height 0→100% via rAF to force a WKWebView reflow
3. Inside the iframe (React SPA) we use visualViewport.height || documentElement.clientHeight per WebKit #170595, ResizeObserver on documentElement, plus a position: fixed; inset: 0 PierBover-style wrapper

All three live, still collapsing to ~1/3 after 20+ background/foreground cycles in HA Companion iOS 26.

So the CSS-only path doesn't seem to be enough here. Probably the iframe layout cache in WKWebView is going stale at a deeper level. PR #29681 may work for ha-panel-custom due to a different rendering path. For hui-iframe-card / panel_iframe we'd probably need a JS-side workaround too (forced iframe re-attach on visibilitychange/pageshow, or similar).

If anyone has a JS-side idea worth trying, I can test it.

Env: HA Core 2026.4.2 (Container), Frontend 20260325.7, iOS 26, React 18 + Vite SPA in the iframe.

[shrey239]

Thanks for testing all of those layers — that definitely rules out the straightforward CSS/dvh path.

Given that:

• 100vh + 100dvh
• forced height reflow
• visualViewport
• ResizeObserver
• fixed inset wrapper

are all already in place, this does seem more like a stale WKWebView compositing/layout state than a normal viewport calculation issue.

One thing that might be worth testing is forcing a full iframe remount/re-attach on lifecycle events instead of only triggering style recalculation.

Possibly something along the lines of:

• listen for visibilitychange / pageshow
• temporarily remove the iframe node from DOM
• reinsert it in next rAF/microtask
• or force a src reassignment to itself as a last-resort invalidation path

Something like:

const parent = iframe.parentNode;
const next = iframe.nextSibling;

parent.removeChild(iframe);

requestAnimationFrame(() => {
  if (next) {
    parent.insertBefore(iframe, next);
  } else {
    parent.appendChild(iframe);
  }
});

Main reason I’m thinking along those lines:
the fact that Safari itself behaves correctly but HA Companion does not suggests the issue may sit inside WKWebView’s retained rendering/compositing state after repeated suspend/resume cycles.

Another possible angle:

• toggling display: none -> block
• toggling contain
• forcing a synchronous layout read (offsetHeight/getBoundingClientRect)
  before restoring dimensions

Though I suspect a true DOM detach/attach may invalidate more internal WebKit state than style mutations alone.

Curious whether the collapse persists after a hard iframe remount.

[dalvonc]

Tried the hard detach with a 5s threshold (so brief switches don't trigger reload). Verified the detach fires correctly via console, but iframe still collapses after 20+ background/foreground cycles on iPhone iOS 26 + HA Companion.

At this point we've exhausted CSS + DOM-level workarounds from both inside and outside the iframe:

• 100vh + 100dvh via card-mod
• postMessage flip iframe.style.height 0→100%
• Hard detach + reattach
• React bundle rename to force fresh fetch

The same React app accessed via iOS Safari directly works perfectly under the same stress test, so the corruption is specifically inside HA Companion's WKWebView lifecycle, not the iframe content.

Leaving #52049 open — looks like the remaining angle is something only the HA frontend / iOS team can do, possibly a native-side WKWebView invalidation or a fresh WebContent process on applicationDidBecomeActive. From the iframe child or HA-side JS we've hit the ceiling.

Thanks for the suggestions, definitely helped rule out the obvious paths.