Chrome hydration issue for remix apps in iframes, and how to solve it

[emilbjorklund]

Hello! This topic is more of a documentation of a browser bug in Chrome/Chromium-based browsers which seems to hit Remix apps when using the stock code for hydrating them – when running inside of an iframe. Since my team spent a lot of time tracking this down, I thought I'd document the issue somewhere, so that someone searching for it at least has a chance to find some help. This is not a remix-specific bug, to be clear, hence I hesitate to post it as an issue.

The bug

The bug manifests like this:

1. SIte A loads cross-origin Site B (a remix app) inside of an iframe, with the criterion that Site A is not visited via any localhost origin.
2. The requestIdleCallback for hydrating the Remix app does not fire, somewhat intermittently - at least until the user does something to "activate" the iframe - clicking, moving their mouse over it, scroll it, focus an element etc.
3. This then (obviously) means that any client-side code in react land will not run, or at least not run with the timing you assume, which is how we found the bug.

There is a bug filed from 2021 which documents this exact issue and has a reproducible example in a repo. Sadly, the chrome team misread how to reproduce it and closed the bug due to inactivity. I have commented on the bug in hopes that it will be reopened and examined further.

How to get around it

The code you get when starting a new Remix project, inside entry.client, looks something like this:

if (window.requestIdleCallback) {
  window.requestIdleCallback(hydrate);
} else {
  // Safari doesn't support requestIdleCallback
  // https://caniuse.com/requestidlecallback
  window.setTimeout(hydrate, 1);
}

You can either opt out of using requestIdleCallback fully and just use window.setTimeout(hydrate, 1);, but in order to use the benefits of requestIdleCallback in browsers that do support it, you can also set up hydration with setTimeout and race the two. You then cancel the one that lost the race.
In that scenario, it probably makes sense to not use a too small timeout, since that might negate the intent of requestIdleCallback, at least that's how I figure it.

let hydrationIdleCallback = 0;
const hydrationTimeoutInCaseChromeNeverFiresIdleTimeout = window.setTimeout(() => {
  window.cancelIdleCallback(hydrationIdleCallback);
  hydrate();
}, 100);
if (window.requestIdleCallback) {
  hydrationIdleCallback = window.requestIdleCallback(() => {
    window.clearTimeout(hydrationTimeoutInCaseChromeNeverFiresIdleTimeout);
    hydrate();
  });
} else {
  // Safari doesn't support requestIdleCallback
  // https://caniuse.com/requestidlecallback
  window.setTimeout(hydrate, 1);
}