|
|
@@ -0,0 +1,29 @@
|
|
|
+# HG changeset patch
|
|
|
+# User Ben Kelly <ben@wanderview.com>
|
|
|
+# Date 1521458940 -7200
|
|
|
+# Node ID a17d9a6aee914f7737a949bbd3fdc738c357c549
|
|
|
+# Parent a5e7168378fe25ab203b93594c6119996d8fe19c
|
|
|
+Bug 1443850 P1 Don't try to apply the request fragment to an empty response URL when perform service worker interception. r=asuth
|
|
|
+
|
|
|
+diff --git a/dom/workers/ServiceWorkerEvents.cpp b/dom/workers/ServiceWorkerEvents.cpp
|
|
|
+--- a/dom/workers/ServiceWorkerEvents.cpp
|
|
|
++++ b/dom/workers/ServiceWorkerEvents.cpp
|
|
|
+@@ -691,17 +691,17 @@ RespondWithHandler::ResolvedCallback(JSC
|
|
|
+ responseURL = ir->GetUnfilteredURL();
|
|
|
+
|
|
|
+ // Similar to how we apply the request fragment to redirects automatically
|
|
|
+ // we also want to apply it automatically when propagating the response
|
|
|
+ // URL from a service worker interception. Currently response.url strips
|
|
|
+ // the fragment, so this will never conflict with an existing fragment
|
|
|
+ // on the response. In the future we will have to check for a response
|
|
|
+ // fragment and avoid overriding in that case.
|
|
|
+- if (!mRequestFragment.IsEmpty()) {
|
|
|
++ if (!mRequestFragment.IsEmpty() && !responseURL.IsEmpty()) {
|
|
|
+ MOZ_ASSERT(!responseURL.Contains('#'));
|
|
|
+ responseURL.Append(NS_LITERAL_CSTRING("#"));
|
|
|
+ responseURL.Append(mRequestFragment);
|
|
|
+ }
|
|
|
+ }
|
|
|
+
|
|
|
+ UniquePtr<RespondWithClosure> closure(new RespondWithClosure(mInterceptedChannel,
|
|
|
+ mRegistration,
|
Ian Neal