@mike: ack, guess its worth specifying. My first guess is that it belongs in Fetch, around keepalive request termination, rather than HTML. It would need to describe best-effort behavior during an orderly last-window close, while excluding explicit quit, crashes, and OS termination. Testing this interoperably may require an external WebDriver/server harness rather than a normal in-browser WPT. I will file a Fetch issue to start that discussion.
@PhistucK: content embedders do not get the process-lifetime behavior automatically. Content invokes the new ContentBrowserClient callbacks, but their default implementations are no-ops. The actual browser/profile holds are implemented in ChromeContentBrowserClient, using Chrome’s ScopedKeepAlive and ScopedProfileKeepAlive. Full Chromium forks carrying the Chrome layer will likely inherit it, content-only embedders would need their own lifecycle implementation. @Marshall: The new hold currently follows the full KeepAliveURLLoader lifetime. The usual detached-loader limit is 30 seconds, but retry-enabled requests can extend that to their retry age, currently bounded at up to one day. Explicit user-requested quit bypasses normal keep-alives, but last-window shutdown and restart eligibility can still be delayed much longer than expected. -- 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/CAFmjHKT5vcL%3D0etHFPpi5V_qiH%2Bv-wGnY55D2M7zLMX_oDrFrw%40mail.gmail.com.
