On Thu, Aug 27, 2026 at 1:36 PM Noam Rosenthal <[email protected]> wrote:
> 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. It would be interesting to know if there was user data to back this up one way or another. > > 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"). > Really? How? Via a service worker or by intercepting a key stroke? Even if they can, it seems like doing so might be a bad idea, UX-wise ... > 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. > True, it probably wouldn't make it easier to track things than an SPA does. > > 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. > I don't actually see the words "first render" in that spec (or anywhere else in the HTML standard), but I do see "during the first `update the render` step" in a Note, so I'm guessing that's what you're referring to. Maybe the text should say "before the pagereveal event first" or "before the first `update the render` step that display up-to-date content", or the text should explicitly define "first render" as that? Cheers. -- Dirk > > > > 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/CALyq14_tqv8P2e7TPbVOJiPaKkASGe6mJ0gD-9JOthhm2wL7-w%40mail.gmail.com.
