There are certainly cases where this feature would be useful, but I have concerns that this might be something of a double-edged sword: it seems to me that this also has the possibility of causing confusion and possibly real problems, and I didn't see any discussion of my concerns in the explainer (apologies if I missed something ...).
For example, for at least some part of the internet's user base, users are used to the idea that if you click on a link the entire page is unloaded and a new page is loaded, and things *aren't* persisted. Given that, any plans to make it apparent when something is being persisted? E.g., something showing up in the address bar or something? Otherwise, users might wonder why something isn't going away when they navigate to a new page. [I grant that the intercepting clicks on links and buttons to avoid page loads, and the use of SPAs and things like `history.pushState()` have long blurred this line, and that probably another, larger part of the user base doesn't really understand loading and unloading at all.] Perhaps more importantly, I think people may be used to the idea that navigating does reset state and that navigating away and back from a page can be used as a way to try and reset things (intentionally). And, this might break that expectation. Will there be some way to force these things to be unloaded and destroyed? E.g., a hard refresh? If not, this seems like this might introduce debuggability problems and make it harder for users to recover from problems (although I don't know how many people are even aware of hard refreshes ...). And even if there is, I'm a bit concerned that this won't be the default. Going even further, it seems like it might be possible to abuse this, e.g., to persist invisible iframes that can then track activity across pages even when the user isn't aware that that's happening. [Again, I realize that since everything is same-origin, this probably isn't introducing any new vectors for things that can't already be done, just with more difficulty, but I'm not sure that tracking easier by default is a great idea.] To be clear, I'm not saying this feature is a bad idea. I'm not actually sure how I feel about it yet. But, I would feel better about it if the explainer (or something else) addressed these concerns. Side note: can you say more about what "3. The <persistentwidget> element must be attached to the new document before its first render" means? I'm not sure if this is a term of art I'm not aware of, but I'm guessing that this means either the element must either appear in the initial page source or be injected at or before onload() completes or something? Hope this is useful, -- Dirk On Wed, Aug 26, 2026 at 2:23 PM Joey Arhar <[email protected]> wrote: > *Contact emails* > [email protected] > > *Explainer* > https://github.com/WICG/persistent-iframes > > *Specification* > *No information provided* > > *Summary* > Persistent widgets are embedded browsing contexts, like iframes, but they > can persist across same-origin navigations without reloading. Persistent > widgets can be used via the <persistentwidget> HTML element. The > <persistentwidget> HTML element takes a src attribute, like an iframe. In > order to make the <persistentwidget> survive a navigation, all of these > conditions must be met: 1. The navigation must be to a same-origin > document. 2. The <persistentwidget> element must have the same src and id > HTML attributes in both documents. 3. The <persistentwidget> element must > be attached to the new document before its first render. > > *Blink component* > Blink>HTML > <https://issues.chromium.org/issues?q=customfield1222907:%22Blink%3EHTML%22> > > *Web Feature ID* > Missing feature > > *Motivation* > Hard navigations of top-level documents result in the destruction of all > the child iframes of those documents. In cases of same-origin navigations, > there's high likelihood that at least some of those iframes would need to > be recreated on the new document. For iframes maintaining complex > client-side state (e.g. chat widgets, media players, collaborative editing > sessions, payment flows, embedded third-party apps), that results in loss > of state and user-visible performance implications. This significantly > disadvantages MPA architectures (that rely on hard same-origin navigations) > compared to SPA architectures, that can soft-navigate parts of the document > while leaving the iframes intact. That is particularly problematic for the > use-case of in-page agents, and runs a risk of causing web developers to > prefer SPAs due to that, despite potential performance and maintenance > costs related to that preference. > > *Initial public proposal* > https://github.com/WICG/persistent-iframes > > *Goals for experimentation* > None > > *Requires code in //chrome?* > False > > *Tracking bug* > https://issues.chromium.org/issues/537818859 > > *Estimated milestones* > > No milestones specified > > > *Link to entry on the Chrome Platform Status* > https://chromestatus.com/feature/5155555348971520?gate=6206129112743936 > > This intent message was generated by Chrome Platform Status > <https://chromestatus.com/>. > > -- > You received this message because you are subscribed to the Google Groups > "blink-dev" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > To view this discussion visit > https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwJsC353neof5Pau%2BDSAP0F85-oCTizBS8oipsg7PoNRhQ%40mail.gmail.com > <https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CAK6btwJsC353neof5Pau%2BDSAP0F85-oCTizBS8oipsg7PoNRhQ%40mail.gmail.com?utm_medium=email&utm_source=footer> > . > -- You received this message because you are subscribed to the Google Groups "blink-dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/blink-dev/CALyq14-_7xRdY9M6Umso9ssg9vi0xWwgp4jaB2R9Yxi7ZK2rZA%40mail.gmail.com.
