+desktop-pwas-team as FYIOn Wed, Nov 30, 2022 at 11:43 AM Łukasz Anforowicz <luk...@chromium.org> wrote:Hello content...@chromium.org,I would like to improve the documentation and the shared knowledge about best practices for managing the lifetime of `content::WebContents`. I would very much appreciate feedback and discussion on this topic.Some notes to get the discussion started:
- This email is motivated by seeing bugs that can be root-caused to WebContents that haven't been closed before a BrowserContext/Profile shutdown. Example: https://crbug.com/1376879
- This email is also motivated by the realization that I don't really know what the best practices are for managing the lifetime of WebContents in the //chrome layer or the //components layer.
- I am only aware of BrowserContextKeyedServiceShutdownNotifierFactory and I am far from sure that this is the best practice and what its alternatives are.
- I assume that no extra work is needed for WebContents added to the tab strip, but I don't know the details.
- AFAIK //content/OWNERS have pushed back in the past on having a centralized repository/knowledge of all WebContents (i.e. when introducing ChromeContentBrowserClient::OnWebContentsCreated).
- Still, maybe we could consider having BrowserContext track a //content-internal `std::set` of `WeakPtr<WebContents>` associated with a given BrowserContext and then in BrowserContext's destructor we could DCHECK/DwoC/CHECK that there are no WebContents left (logging the same crash keys as in RenderFrameHostImpl::AssertBrowserContextShutdownHasntStarted).
- I hope that our conclusion can eventually be captured in the repo somewhere (//content/public/browser/web_contents.md? doc comment in //content/public/browser/web_contents.h?). It is a bit unfortunate that the doc comment of `content::WebContents::Create` doesn't say anything about lifetime expectations (it just says: "Creates a new WebContents.").
Thanks,Lukasz
--
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 on the web visit https://groups.google.com/a/chromium.org/d/msgid/content-owners/CA%2B4qT318bboeV9Qq-LGdTuwQ5%3DCDH0fS9ykWKNHqwf_wNydgUQ%40mail.gmail.com.
To unsubscribe from this group and stop receiving emails from it, send an email to content-owners+unsubscribe@chromium.org.
Hi Łukasz,I think it is important to note that the lifecycle of a WebContents is quite clear - the caller of WebContents::Create() owns the WebContents object and is responsible for destroying it. For WebContents shown in the tab strip, I think the Browser owns them and all the Browser objects are destroyed when the windows are closed. I do not think the lines below fits in WebContents::Create documentation though.You have 2 ways to be notified about Profile destruction:
* your code is running in a Profile Keyed Service, then override KeyedService::Shutdown() - this method will be called when the profile object is destroyed.
* your code is running in a Profile Keyed Service, then override KeyedService::Shutdown() - this method will be called when the profile object is destroyed.