[webkit-changes] [WebKit/WebKit] 997847: [Unified PDF] [iOS] Safari loading blank PDF docum...

[Abrar Rahman Protyasha]

  Branch: refs/heads/main
  Home:   https://github.com/WebKit/WebKit
  Commit: 9978479e764ea5982422797cfc2ea513c098269e
      https://github.com/WebKit/WebKit/commit/9978479e764ea5982422797cfc2ea513c098269e
  Author: Abrar Rahman Protyasha <a_protyasha at apple.com>
  Date:   2025-02-27 (Thu, 27 Feb 2025)

  Changed paths:
    M Source/WebCore/dom/Document.cpp

  Log Message:
  -----------
  [Unified PDF] [iOS] Safari loading blank PDF document when served with Content-Disposition: attachment HTTP header
https://bugs.webkit.org/show_bug.cgi?id=288432
rdar://143879793

Reviewed by Tim Horton.

If a PDF file is served with the `Content-Disposition: attachment` HTTP
header, then we place sandbox restrictions on said file in Cocoa ports.

In macOS, Safari provides a download prompt for the file. In iOS,
without Unified PDF enabled, the file is display inline regardless for
main frame documents, while <embed>/<iframe> elements cause a download
prompt to be presented. However, with Unified PDF enabled, we  now sink
the data in DocumentWriter as we are about to create a PluginDocument,
leaving us with blank content instead for main frame documents.

This patch bridges the gap between shipping and Unified PDF on iOS, by
freeing the PluginDocument off of plugin sandbox restrictions that we
choose to apply as part of our general strategy for Content-Disposition:
attachment headers.

Tested manually for now. https://webkit.org/b/288435 tracks landing an
automated test for this.

* Source/WebCore/dom/Document.cpp:
(WebCore::Document::applyContentDispositionAttachmentSandbox):

Canonical link: https://commits.webkit.org/291285@main



To unsubscribe from these emails, change your notification settings at https://github.com/WebKit/WebKit/settings/notifications