`"use cache"`'d components do not update during HMR inside an iFrame

[rikbrown]

Link to the code that reproduces this issue

https://github.com/rikbrown/nextjs-use-cache-in-iframe-hmr

To Reproduce

1. Start the application in dev mode, go directly to URL.
2. Make changes in the CacheComponent component in page.tsx, observe HMR.
3. Now go to the page in an iFrame (either a local html file or remote - I put one in the repo)
4. Make changes, observe no HMR
5. HARD refresh, observe updated value,
6. Make changes, observe no HMR.

Current vs. Expected behavior

HMR should occur without needing a hard refresh.

Provide environment information

bun next info

Operating System:
  Platform: darwin
  Arch: arm64
  Version: Darwin Kernel Version 25.3.0: Wed Jan 28 20:48:41 PST 2026; root:xnu-12377.81.4~5/RELEASE_ARM64_T6041
  Available memory (MB): 131072
  Available CPU cores: 16
Binaries:
  Node: 22.18.0
  npm: 10.9.3
  Yarn: 1.22.22
  pnpm: 10.28.2
Relevant Packages:
  next: 16.2.0-canary.50 // Latest available version is detected (16.2.0-canary.50).
  eslint-config-next: N/A
  react: 19.2.3
  react-dom: 19.2.3
  typescript: 5.9.3
Next.js Config:
  output: N/A

Which area(s) are affected? (Select all that apply)

Use Cache

Which stage(s) are affected? (Select all that apply)

next dev (local)

Additional context

Tested on latest stable and canary.

Tested w/ "allow third party cookies off".

Verified if I manually disable caches in the chrome dev tools, HMR does work.

The crazy thing to me is if I then open the iFrame in a totally different browser, it is still out of date. But opening the exact same URL, just not in an iframe, is up to date. This is beyond my comprehension of how Next.js caches things.

[icyJoseph]

Hi, I can't repro...

Screen.Recording.2026-02-18.at.21.05.31.mov

Could you verify that the websocket transfers data? Perhaps you need https://nextjs.org/docs/app/api-reference/config/next-config-js/allowedDevOrigins

[rikbrown]

It definitely connects and transfers data. Let me try to repro again and screen capture.

[rikbrown]

Screen.Recording.2026-02-18.at.20.27.35.mov

I started by hard refreshing and verifying WS.
Then I made a change - you can see events in the WS, but no HMR update.
Then I hard refreshed again at the very end to see the update.

[rikbrown]

Let me know if any diagnostics/WS output would be helpful.

[rikbrown]

I think the WS looks normal?

down {"type":"building"}
down {"type":"serverComponentChanges","hash":"31"}
up {"event":"server-component-reload-page","clientId":1771446470130,"hash":"31"}
down {"type":"cacheIndicator","state":"ready"}
down {"type":"built","hash":"32","errors":[],"warnings":[]}
up {"event":"client-success","clientId":1771446470130}
up {"event":"client-hmr-latency","startTime":1771446871002,"endTime":1771446871018,"page":"/","updatedModules":[],"isPageHidden":false}

(note I also tried adding a button that does router.refresh() to no avail if that is helpful context)

[icyJoseph]

Does it also happen if you serve the host page? I see you are using file system file:///, https://www.npmjs.com/package/serve

[rikbrown]

Interesting, using serve and serving this file on localhost it does not reproduce anymore. However, I originally hit this issue in the following setup:

1. Next.js dev server running on https://localhost:3000 (note https if relevant)
2. Remote Cloudflared tunnel in iFrame (with remote Next.js exposed - HMR working fine when viewing in browser).

Is there some weirdness going on related to conflicting origins or something? Let me try a simple repro via the original setup.

[rikbrown]

Ok I can consistently repro in that setup, try this:

1. Start local dev server
2. cloudflared --url http://localhost:3000
3. Take that URL and put it into your local iframe.html and serve it
4. View iFrame and make HMR changes.

[icyJoseph]

Right, and if you add the URL you get from cloudflared into https://nextjs.org/docs/app/api-reference/config/next-config-js/allowedDevOrigins... then? I guess you need to do some pattern matching

[rikbrown]

No it doesn't, but it would be the other direction though right? As it's the iFrame connecting to the dev server running behind cloudflared.

For avoidance of doubt I added it along with localhost though - no dice.

The WS is connecting, doesnt seem to be getting blocked and no warnings in logs.

[icyJoseph]

Interesting, I'll do some testing of my own soon, but try with --webpack - just to discard the bundler as well.

I've used Vercel Sandbox, through an iframe w/ HMR and all, to make a small live editor, why would this not work just the same 🤔 protocol downgrade? (https -> http?) but my live editor ran on localhost with the sandboxes no problem.

[rikbrown]

I even just tested a setup where I run:

1. next dev -> cloudflare
2. serve -> cloudflare
   and have the serve iFrame iFraming the other cloudflare, just incase it was some local vs remote origin or protocol thing and seems to no avail. I am pretty confident the WS is running correctly - it does HMR if you remove 'use cache' after all.

[rikbrown]

Trying tried webpack, same problem.

[icyJoseph]

Can you add sandbox="allow-scripts allow-same-origin" to the iframe, mostly thinking of the same-origin thing. I remember there was a bug w/ cache components, related to the Path in the cookie NEXT_HMR_REFRESH_HASH_COOKIE, https://github.com/vercel/next.js/pull/82776/changes - it could be that the iframe is getting an opaque origin

I am guessing right now, I still haven't had time to setup to try things out 🥲