[Webkit-unassigned] [Bug 260771] REGRESSION(2.42): PDF "Save" button does nothing, "Print" function also broken

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=260771

--- Comment #17 from Michael Catanzaro <mcatanzaro at redhat.com> ---
So I think following the spec is impossible and WebKit already does not attempt to do so. I'm looking at https://url.spec.whatwg.org/#origin (currently section 4.7 "Origin") and it's clear that the security origin of URLs for most protocols is defined to be always opaque. The only exceptions are blob, ftp, http, https, ws, wss, and file.

But if we were to do that, then there's just no way that custom protocols can ever work. WebKit's SecurityOriginData::shouldTreatAsOpaqueOrigin already has a big list of WebKit protocols that should receive non-opaque security origins, including a bunch of Apple-specific ones (applewebdata, x-apple-ql-id, x-apple-ql-id2, x-apple-ql-magic) and the Linux-specific resource:// protocol. The list is there because the alternative to make the protocols work would be to disable same origin policy entirely, which would be much worse. For example, webkit-pdfjs-viewer pages should be able to load other webkit-pdfjs-viewer pages with the same security origin. resource pages should be able to load other resource pages. If the origins are opaque, it cannot work.

So I think this is OK. The spec handles standard web protocols. We can say we're extending it for the benefit of WebKit-specific protocols and custom protocols.

I'm now I'm wondering if isSafelistedBlobProtocol can be replaced by SecurityOriginData::shouldTreatAsOpaqueOrigin:

diff --git a/Source/WebCore/page/SecurityOrigin.cpp b/Source/WebCore/page/SecurityOrigin.cpp
index 605e0523d462..488d13c5befa 100644
--- a/Source/WebCore/page/SecurityOrigin.cpp
+++ b/Source/WebCore/page/SecurityOrigin.cpp
@@ -169,18 +169,6 @@ Ref<SecurityOrigin> SecurityOrigin::create(const URL& url)
     return adoptRef(*new SecurityOrigin(url));
 }

-inline bool isSafelistedBlobProtocol(const URL& url)
-{
-    if (!url.isValid())
-        return false;
-
-    // FIXME: we ought to assert we're in WebKitLegacy or a web content process as per 263652 at main,
-    // except that assert gets hit on certain tests.
-    return url.protocolIsInHTTPFamily()
-        || url.protocolIsFile()
-        || LegacySchemeRegistry::schemeIsHandledBySchemeHandler(url.protocol());
-}
-
 Ref<SecurityOrigin> SecurityOrigin::createForBlobURL(const URL& url)
 {
     ASSERT(url.protocolIsBlob());
@@ -189,7 +177,7 @@ Ref<SecurityOrigin> SecurityOrigin::createForBlobURL(const URL& url)
         return origin.releaseNonNull();

     URL pathURL { url.path().toString() };
-    if (isSafelistedBlobProtocol(pathURL))
+    if (!SecurityOriginData::shouldTreatAsOpaqueOrigin(pathURL))
         return adoptRef(*new SecurityOrigin(pathURL));

     return createOpaque();

I think I'll try this....

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20230929/a348810a/attachment.htm>