| Summary: | [GTK] Excessive memory usage from WebKitWebViewSessionState | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Guilaume Ayoub <guillaume.webkit> |
| Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW --- | ||
| Severity: | Normal | CC: | bugs-noreply, kdwkleung, mcatanzaro, nekohayo, webkit-bug-importer |
| Priority: | P2 | ||
| Version: | Other | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
| See Also: | https://bugs.webkit.org/show_bug.cgi?id=268410 | ||
|
Description
Guilaume Ayoub
2023-11-15 08:40:29 PST
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 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. (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. Sorry, bug #115600 was where this API was introduced. I meant to link to bug #153230. 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. (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. |