Failed DCHECK in GetWindowClientInfoOnUI on prerendered pages |
||
Issue descriptionThis DCHECK fails in GetWindowClientInfoOnUI if you load https://static-misc.glitch.me/resulting-client-message/ enough and then paste it into the omnibox without pressing enter: PageVisibilityState visibility = render_frame_host->GetVisibilityState(); // Service workers do no prerender, this would be an invalid visibility state. DCHECK_NE(visibility, PageVisibilityState::kPrerender); The site is doing: client = await clients.get(event.resultingClientId); client.postMessage('hi'); If the DCHECK is removed, the postMessage gets dropped because there is no ServiceWorkerProviderHost created for the page, even though clients.get(id) resolved for it. An open question seems to be: What is a prerendered page and how should the Clients API expose them if at all? It seems to me we should just not resolve clients.get() on a prerendered page.
,
Today
(13 hours ago)
The "prerendered" page here is the one instantiated with nostate-prefetch, which sets kPrerender here (I think): https://codesearch.chromium.org/chromium/src/chrome/browser/chrome_content_browser_client.cc?type=cs&q=%22visibility_state+%3D+content::PageVisibilityState::kPrerender%22&sq=package:chromium&g=0&l=4329 The RFH visibility state then will get stuck at kPrerender for the lifetime of the RFH. The PostMessage should not be handled by the client because we should not allow running JS in the document under nostate-prefetch - that's by design. I am not sure how we avoid creating ServiceWorkerProviderHost and whether it is risky to avoid creating it. Even if it is created, it will likely never be consulted to under kPrerender. So I think: 1. we should just remove the DCHECK 2. PostMessage not working looks WAI 3. it is easy to make SW to be blind to clients under kPrerender, but I think it may confuse more SWorkers if we do this (vs. returning the clients that do nothing) falken: WDYT?
,
Today
(3 hours ago)
Thanks pasko. I was thinking about making clients.get() not resolve for nostate-prefetch clients, since we already delay clients.get() until "execution ready" and a Document that can't run JS sounds like not "execution ready": https://html.spec.whatwg.org/multipage/webappapis.html#concept-environment-execution-ready-flag But I think I like just resolving it and dropping PostMessages: 1. It'd be surprising for service workers to get fetch requests for subresources from the Document when clients.get() still hasn't resolved. 2. PostMessage just dropping seems in line with the "don't run JS" restriction of the document. I also don't understand why SWPH wouldn't be created and am somewhat surprised things work without it. I'm guessing the provider host was originally created (it has to be for a client id to even exist) and by the time the SW calls clients.get() it's been destroyed for some reason. Would need more investigation. |
||
►
Sign in to add a comment |
||
Comment 1 by danakj@chromium.org
, Yesterday (37 hours ago)