264879 2023-11-15 08:40:29 -0800 [GTK][WPE] Limit memory used by target strings serialized in WebKitWebViewSessionState 2025-03-18 02:41:13 -0700 1 1 1 Unclassified WebKit WebKitGTK Other Unspecified Unspecified RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=268410 https://bugs.webkit.org/show_bug.cgi?id=289945 P2 Normal --- 1 guillaume.webkit webkit-unassigned aperez bugs-noreply kdwkleung mcatanzaro nekohayo webkit-bug-importer oldest_to_newest 1992798 0 guillaume.webkit 2023-11-15 08:40:29 -0800 More information about this bug can be found here: https://gitlab.gnome.org/GNOME/epiphany/-/issues/1610 1994433 1 mcatanzaro 2023-11-22 12:14:32 -0800 I'm not sure we're even gaining much anything from all this memory use. The point of serializing the state of the web view is to be able to restore it instantly without having to load everything again. And for Apple ports this actually happens, but for GTK/WPE we do a new load anyway to ensure we don't display stale content. (E.g. it would be really confusing to open your browser to this Bugzilla page and not see new comments posted since the last time you manually reloaded the page, which could be days or weeks ago.) 1994486 2 kdwkleung 2023-11-22 21:14:17 -0800 I think the ideal experience would be to restore the old page first, then do a fresh load in the background, and switch to that when the new one has been fully loaded. 1996214 3 mcatanzaro 2023-12-01 07:28:08 -0800 (In reply to Michael Catanzaro from comment #1) > I'm not sure we're even gaining much anything from all this memory use. The > point of serializing the state of the web view is to be able to restore it > instantly without having to load everything again. And for Apple ports this > actually happens, but for GTK/WPE we do a new load anyway to ensure we don't > display stale content. (E.g. it would be really confusing to open your > browser to this Bugzilla page and not see new comments posted since the last > time you manually reloaded the page, which could be days or weeks ago.) I did some archaeology and found bug #115600 was where we agreed to disable this. I wonder if we should revisit this choice. Anyway, that won't fix this bug; it would only make the excessive memory use worth something. Right now I suspect it's all wasted. 1996215 4 mcatanzaro 2023-12-01 07:28:37 -0800 Sorry, bug #115600 was where this API was introduced. I meant to link to bug #153230. 2011784 5 mcatanzaro 2024-02-08 09:25:08 -0800 Apple recommends we limit the size of the session state in our platform-specific code, bug #268410. I think this is acceptable; it should be OK to drop the session state if it gets too large. That said, ideally we should not attempt to save the entire page cache into session state. It should be sufficient to save only the current page. Serializing everything in the back/forward list just to make the back button work faster after the browser is closed and reopened is overkill. 2011788 6 guillaume.webkit 2024-02-08 09:30:39 -0800 (In reply to Michael Catanzaro from comment #5) > Apple recommends we limit the size of the session state in our > platform-specific code, bug #268410. I think this is acceptable; it should > be OK to drop the session state if it gets too large. It would definitely work for me, as my current "solution" is a sed command removing the history attribute from session_state.xml when it gets too large. 2103753 7 mcatanzaro 2025-03-17 07:35:40 -0700 *** Bug 289898 has been marked as a duplicate of this bug. *** 2103844 8 ews-feeder 2025-03-17 15:13:44 -0700 Committed 292282@main (99f7a1b31bae): <https://commits.webkit.org/292282@main> Reviewed commits have been landed. Closing PR #42568 and removing active labels. 2103845 9 guillaume.webkit 2025-03-17 15:19:12 -0700 Thanks a lot! 💘 2103959 10 aperez 2025-03-18 02:41:13 -0700 @Guillaume: No problem at all! We may be able to make the session state somewhat smaller by limiting the total size stored, see bug #289945 for that.