This is a very interesting idea for creation of complex web applications comparable in functionality to regular desktop apps, especially media applications (e.g., looking at YouTube, which struggles with minimized video playback).
What are the exact criteria for attaching the Persistent Widget to the document? The explainer mentions "Upon loading Page B, the browser matches the <persistentwidget> element with the same id and resolved src URL." Do you match based on path alone or the complete URL, including URL decorations (like query parameters with `?` and `&` and section specifiers `#`) or some other excerpt from it? Is widget permitted to use History API to change its own path and thus potentially affect its matching criteria? Is Persistent Widget capable of using `<a href="#section">` to link to a different section within it (and if so, how that affects the matching key)? While id is supposed to be unique, web developers occasionally break this rule and have duplicate ids, so how does browser resolve contention between multiple attachment points with the same match key and multiple widgets with the same match key? Could you please flash out a bit more how Persistent Widgets integrate with back-forward cache (BFCache) and especially prerendering and closed tab/window restoration (Ctrl+Shift+T)? The process of navigating forward is mentioned in explainer: the widget is never part of the host document, so when user navigates forward from host document A to host document B gets detached from A and re-attached to B, unless B failed to load, in which case widget is still attached to A. Is the process of backward navigation the same (with the only exception that document restored from BFCache never fails to load)? What if current document and a prerendered document have attachment points with the same key? Since widget can not be detached from the currently visible document, then it can not be attached to prerendered document, so it prerendered document creates a separate instance of the widget. Do you plan to make Persistent Widgets compatiable with Picture in Picture? Thanks. On Friday, August 28, 2026 at 2:02:40 AM UTC+3 [email protected] wrote: > 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/d04d19b1-6168-4823-a5ce-cd670a6c2c2cn%40chromium.org.
