On Thu, Aug 27, 2026 at 7:56 PM Dirk Pranke <[email protected]> wrote: > > 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.]
This is a key point though. SPAs are so ubiquitous in 2026 that the line is non-existent IMO. People don't expect navigation to reset the state. > > 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. Given the above point, I don't think people are used to that idea anymore. Also things like `localStorage` service workers and other aspects stay alive on navigations. I think that the notion that a navigation is a state reset is useful, but if taken too rigidly, it pushes people towards an SPA architecture that breaks all these assumptions from the start (SPAs can even intercept "hard refresh"). So in this middle-ground architecture, the app state fully resets, but the chat widget or YouTube video stays alive. I think that's a win over forcing people into a full-SPA or full-state-resetting-MPA architecture. > > 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.] If you compare with existing MPAs, maybe you're right. Compared to SPAs, this might not make tracking easier because it allows adopting an MPA architecture for the rest of the UI. > 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? The first render is well defined in the spec (https://html.spec.whatwg.org/multipage/browsing-the-web.html#reveal). It is where we fire the `pagereveal` event. > > 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 >> >> 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. >> >> -- >> 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. > > -- > 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. -- 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/CAJn%3DMYZ7XzRVBD8MnH2dwA1tDBqgc7AgtYuX8-7NeDw8fjchwA%40mail.gmail.com.
