Re: [chromium-dev] Re: FR: Observer for Page's LifecycleState? PageLifecycleObserver?
14 views
Skip to first unread message
Daniel Murphy
Dec 9, 2025, 12:44:20 PM12/9/25
to Sidhin Thomas, content-owners, Chromium-dev
As per suggestion by dcheng, +content-owners to see if anyone is thinking about stuff like this.
On Tue, Dec 9, 2025 at 9:42 AM Daniel Murphy <dmu...@chromium.org> wrote:
Good question. Yes and no. A web contents can be navigated. A page cannot*.Web contents will have the 'primary page changed' for each navigation. That is the recommended way to listen for navigations for primary frame in the WebContentsObserver now.There is a SUPER common pattern (we use it all over the place in PWA code) where someone wants to calculate something on a WebContents, and the basically send the results of that to something else to do something with it (or just store it for reference). But then, it implements all of the navigation listening code to 'clear' that value and recalculate it on the next navigation complete. Even more - it'll often listen to WebContentsDestroyed with is a classic source of bugs (and a presubmit compliains about that).Instead, you can make a PageUserData to store something on a page object itself. This is super great, as it's compatible with BFCache and prerendering (if you want it to be). Any calculations are saved etc. Destruction of the page removes the data. hooray! However - there isn't a way for a PageUserData to listen to its own lifecycle in a simple way. We have code that executes after a page becomes active, and then I want to 'stop' if it enters bfcache.On Tue, Dec 9, 2025 at 9:37 AM Sidhin Thomas <sidhin...@gmail.com> wrote:I have a maybe dumb question, isn't Page == Webcontents in context of the browser?On Tue, Dec 9, 2025 at 11:00 PM Daniel Murphy <dmu...@chromium.org> wrote:There is an observer for this on WebContentsObserver - but we shouldn't need a whole webcontents - we should be able to just observe this on a page.--On Mon, Dec 8, 2025 at 4:00 PM Daniel Murphy <dmu...@chromium.org> wrote:Do we have anything like this? It would be super useful for me to decouple code from the WebContents - as I want to cancel operations when a page goes to kPendingDeletion, and pause it if it goes to kInBackForwardCache.Dan
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/CA%2B4qT30hDh5gbgQm%3DntnOPj8LJsYL4E6CEnqZ3uFYpL%2B7%2BU%2BZw%40mail.gmail.com.
Fergal Daly
Dec 10, 2025, 10:27:40 AM12/10/25
to dmu...@chromium.org, Sidhin Thomas, content-owners, Chromium-dev
On Wed, 10 Dec 2025 at 02:53, Daniel Murphy <dmu...@chromium.org> wrote:
As per suggestion by dcheng, +content-owners to see if anyone is thinking about stuff like this.
I recently added WebContentsBasedCanceller to try to simplify some of what you are talking about. It does not handle resuming something on `pageshow` but I suppose it could.
However it doesn't address your complaint of not need WebContents,
F
Daniel Murphy
Dec 10, 2025, 12:36:43 PM12/10/25
to Fergal Daly, Sidhin Thomas, content-owners, Chromium-dev
I might take a stab at it. In the PWA code, this simplifies a bunch of stuff, and I imagine MANY systems do this:
- Listen for navigation to complete (page to be changed)
- "calculate stuff and save it", "possibly call observers", "call into other areas of code"
- Listen for navigation to start / complete again to clear state and start again
This is incompatible inherently with things like bfcache (and we re-calculate stuff as a result) and cannot easily take advantage of prerendering if it wants to.
For storage, things like a PageUserData allow for storage in an inherently bf-cache compatible way. You COULD store than, and then in the 'navigation complete' check the existing page to see what the state it, and use cached state if it's there.
But wouldn't it be nice to just not have to deal with WebContents at all? Just have a PageUserData that can also listen for lifecycle events on the page itself?
I'll start poking at this if I have time.
Daniel Murphy
Dec 11, 2025, 3:09:57 PM12/11/25
to content-owners, Daniel Murphy, Sidhin Thomas, content-owners, Chromium-dev, Fergal Daly, Devlin Cronin
Idea from +Devlin - since a Page cannot be owned by more than one WebContents (each page has one web contents ), it's not TOO hard to have a WebContentsUserData manage these observers, as it can listen to that event on the WebContentsObserver, and dispatch events..
But - to check - it's true now and into the future that a page has one web contents, and a web contents has many pages?
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev+unsubscribe@chromium.org.
Rakina Zata Amni
Dec 16, 2025, 3:01:30 AM12/16/25
to dmu...@chromium.org, content-owners, Sidhin Thomas, Chromium-dev, Fergal Daly, Devlin Cronin
On Fri, Dec 12, 2025 at 5:04 AM Daniel Murphy <dmu...@chromium.org> wrote:
Idea from +Devlin - since a Page cannot be owned by more than one WebContents (each page has one web contents ), it's not TOO hard to have a WebContentsUserData manage these observers, as it can listen to that event on the WebContentsObserver, and dispatch events..
Chiming in late here, but we can make a special subclass of PageUserData also be WebContentObservers themselves and listen to events happening to the Page it's tracking, and trigger callbacks under certain conditions etc. That's similar to what Fergal's WebContentsBasedCanceller is doing, although that's a bit more specialized. Is that similar to what you're trying to have?
But - to check - it's true now and into the future that a page has one web contents, and a web contents has many pages?
Yes, this is correct now, and I would expect this to hold in the future as well. See also the MPArch design doc which might be a little relevant, I don't think we'll ever want Pages move between WebContents.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
--
--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev
---
You received this message because you are subscribed to the Google Groups "Chromium-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/chromium-dev/c41432fc-4fbb-46f6-9d3f-5f7d93bfa052n%40chromium.org.
Alex Moshchuk
Jan 7, 2026, 8:06:12 PM (2 days ago) Jan 7
to Rakina Zata Amni, dmu...@chromium.org, content-owners, Sidhin Thomas, Chromium-dev, Fergal Daly, Devlin Cronin, Charlie Reis, Liam Brady
Also chiming in late, after this came up in a recent CSA team discussion (also +creis@ and +lbrady@). Do you have an example (maybe in PWA code) of something where the current WCO approach is resulting in too much complexity, and where a new observer would simplify things? This would help us evaluate this proposal more concretely, since at first glance it's non-obvious why it'd be hard to store things in PageUserData and also listen to WCO::RenderFrameHostStateChanged and process lifecycle state changes for Pages associated with main frame RFHs from there, which I think is kind of what Rakina also proposed below.
You received this message because you are subscribed to the Google Groups "content-owners" group.
To unsubscribe from this group and stop receiving emails from it, send an email to content-owner...@chromium.org.
To view this discussion visit https://groups.google.com/a/chromium.org/d/msgid/content-owners/CACPC1r5-1HOXNcV8J7oOPkc9DF-Op7w%3DLrD0Z6pKr6QwNyTgFA%40mail.gmail.com.
Reply all
Reply to author
Forward
0 new messages