Failed to get a ServiceWorkerRegistration: No URL is associated with the caller's document. |
||||||||||
Issue descriptionFrom an internal report (b/67635738), the "Failed to get a ServiceWorkerRegistration: No URL is associated with the caller's document." error message is happening even though they don't expect script-created iframes to be involved (issue 439697). We set the document URL when the request for the navigation arrives, so we expect the URL to be set by the time getRegistration is called from the document. I think this might get fixed with s13n/mojofication, as the browser-side tracking of document URL based on resource requests may go away... not sure though.
,
Nov 13 2017
Leon, Xiaofeng: Do you know what could cause the " No URL is associated with the caller's document" error to occur more often as a result of getRegistration()? I'm curious if the URL check can somehow be removed. It seems the browser shouldn't send the ServiceWorkerRegistrationObjectInfo to the renderer unless it knows the origin of the renderer, somehow can we rely on Mojo endpoints to understand the origin instead of manually in SWProviderHost?
,
Nov 13 2017
I checked around current logic compared with the logic before mojofication for getRegistration(), no idea yet why it occurs more often now..
And sorry I have a question about this problem, should the following 2 getRegistration() return the same thing? From the point view of both spec and current implementations.
<!doctype html>
<iframe id=x></iframe>
<script>
var x = document.getElementById('x');
x.contentWindow.navigator.serviceWorker.getRegistration(xx).then(reg =>
// in case of blank iframe page
);
x.src = 'https://the.current.domain.com/iframepage.html';
x.contentWindow.navigator.serviceWorker.getRegistration(xx).then(reg =>
// in case of iframe page with a valid url
);
</script>
,
Nov 13 2017
I think those are expected to return the same thing in the spec, but not in the current implementation. The iframe without src attribute is an about:blank window and it's supposed to inherit from its parent document. But I think Chrome doesn't do that yet: issue 439697
,
Nov 13 2017
I see, thanks! So for the above case 1 we have to raise the "Failed to get a ServiceWorkerRegistration: No URL is associated with the caller's document." error for now. And the problem of this issue is that it became more often than before and even occurred without script-created iframes involved, right? I can't open b/67635738, I'm curious whether we can find the detailed scenarios there to help investigation..
,
Nov 13 2017
Right, there doesn't seem to be iframes involved yet we're still getting the error.
,
Nov 13 2017
Apologies, b/67635738 should not have been upgraded to P1. The rate has not significantly increased, we just thought it did because of an incorrect query. This happens much more frequently on ChromeOS, in case that gives you any insight. Unfortunately we don't have any repro steps, we just see error reports of this. It happens too infrequently for us to repro at the moment. One user said they were using the product normally, which suggests there weren't iframes involved.
,
Nov 16 2017
Chrome OS also seems to have a high rate of IPC_FAILED during service worker startup so there could be some common cause there.
,
Jan 11 2018
I created a cl to fix a bug in handling "externalfile" scheme URL. https://chromium-review.googlesource.com/c/chromium/src/+/861558 Most error case of ChromeOS will be fixed by this cl. I think non-ChromeOS case of this issue is caused by the race issue 789111.
,
Jan 11 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/38a50a39ec3867e1816e63a0fe116a91692ca99f commit 38a50a39ec3867e1816e63a0fe116a91692ca99f Author: Tsuyoshi Horo <horo@chromium.org> Date: Thu Jan 11 10:18:28 2018 Create ServiceWorkerRequestHandler for ExternalFileScheme When a file in Drive is opened from ChromeOS Files app, Chrome opens "externalfile" scheme URL. And ExternalFileURLRequestJob redirects the request to the Drive's HTTPS URL. Currently ServiceWorkerRequestHandler::InitializeForNavigation() doesn't create a ServiceWorkerProviderHost for the "externalfile" scheme URL. So ServiceWorkerProviderHost is not created during the navigation. A new ServiceWorkerProviderHost will be created when ServiceWorkerDispatcherHost receives OnProviderCreated() IPC from the renderer process. https://chromium.googlesource.com/chromium/src/+/86ff9bc/content/browser/service_worker/service_worker_dispatcher_host.cc#355 But SetDocumentUrl() of the ServiceWorkerProviderHost which is created here will not be called because the navigation is already finished. So all ServiceWorker related API in the page will fail with "No URL is associated with the caller's document." error. Bug: 776408 Change-Id: Ic4a0cd2ec5fb16ff995fb96927ca3fea61c3359a Reviewed-on: https://chromium-review.googlesource.com/861558 Commit-Queue: Tsuyoshi Horo <horo@chromium.org> Reviewed-by: Matt Falkenhagen <falken@chromium.org> Cr-Commit-Position: refs/heads/master@{#528590} [modify] https://crrev.com/38a50a39ec3867e1816e63a0fe116a91692ca99f/content/browser/service_worker/service_worker_request_handler.cc [modify] https://crrev.com/38a50a39ec3867e1816e63a0fe116a91692ca99f/content/browser/service_worker/service_worker_request_handler_unittest.cc
,
Jan 22 2018
horo fixed in 65.0.3319.0. Let's mark this as fixed since the P1 bug that was reported internally was about the Chrome OS files app. If we need to track the general no document url bug, we can do it in a new issue.
,
Jan 22 2018
Ah sorry, the original bug was not 100% CrOS.
,
Aug 1
,
Oct 16
falken@ Does this issue still exist?
,
Oct 29
,
Oct 29
Update on this from our end - this issue now occurs at the same rate for Chrome OS as for other platforms. This seems to indicate that the specific issue when opening from the Chrome OS files app is fixed. However, this does still occur at a rate of about 1 out of every 1000 loads, so the issue still exists in general.
,
Oct 29
aaronsw: ServiceWorkerServicification still has this bug in M70 but it's fixed in M71 ( issue 896157 ). That might help explain the 1 out of 1000 loads. It's enabled at 1% on Stable.
,
Oct 29
Actually, I messed up the denominator for my query. I reran again and it seems like Chrome OS is still higher than the other platforms. The overall rate is lower than before, but still higher for Chrome OS. It's about 0.02% overall and 0.04% for just Chrome OS. I just tried reproducing on a Chromebook and the error still occurs when opening from the Chrome OS app (Chrome 69). Apologies for the confusion. Can you look into this again? It seems like the fix didn't work.
,
Oct 29
,
Nov 2
aaronsn: On Chrome 69 did you have ServiceWorkerServicification on or off? (Will try to test ourselves too)
,
Nov 2
bashi: could you investigate this?
,
Nov 5
I've been trying to repro but couldn't so far. |
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by falken@chromium.org
, Nov 12 2017Owner: falken@chromium.org
Status: Assigned (was: Available)