Changeset 241481 in webkit

Timestamp:

Feb 13, 2019 3:08:26 PM (5 years ago)

Author:

timothy_horton@apple.com

Message:

Encrypted PDFs inside <embed> or <object> crash the Web Content process
​https://bugs.webkit.org/show_bug.cgi?id=194605
<rdar://problem/19894818>

Reviewed by Andy Estes.

Source/WebKit:

• WebProcess/Plugins/PDF/PDFPlugin.mm:

(WebKit::PDFPlugin::createPasswordEntryForm):
Don't try to create a password form field if we can't make form fields.

This means you will be left with a useless embedded PDF, but at least
the Web Content process won't crash.

We'll need to find an alternative implementation of PDF embedded form
fields that is compatible with <embed> and <object> if we want to support
this. Currently we piggy-back off the fact that we can just insert
<input>s into the PluginDocument's DOM, but we can't do that if there
is no PluginDocument, just a main document, like in the <embed> case.

LayoutTests:

• fast/replaced/encrypted-pdf-as-object-and-embed-expected.txt: Added.
• fast/replaced/encrypted-pdf-as-object-and-embed.html: Added.
• fast/replaced/resources/encrypted-image.pdf: Added.

Add a test ensuring that we don't crash with encrypted PDF in <object> or <embed>.

Location:

trunk

Files:

• LayoutTests/ChangeLog (modified) (1 diff)
• LayoutTests/fast/replaced/encrypted-pdf-as-object-and-embed-expected.txt (added)
• LayoutTests/fast/replaced/encrypted-pdf-as-object-and-embed.html (added)
• LayoutTests/fast/replaced/resources/encrypted-image.pdf (added)
• LayoutTests/platform/ios/fast/replaced/encrypted-pdf-as-object-and-embed-expected.txt (added)
• Source/WebKit/ChangeLog (modified) (1 diff)
• Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm (modified) (1 diff)

trunk/LayoutTests/ChangeLog

@@ +1 @@
+2019-02-13  Tim Horton  <timothy_horton@apple.com>
+
+        Encrypted PDFs inside <embed> or <object> crash the Web Content process
+        https://bugs.webkit.org/show_bug.cgi?id=194605
+        <rdar://problem/19894818>
+
+        Reviewed by Andy Estes.
+
+        * fast/replaced/encrypted-pdf-as-object-and-embed-expected.txt: Added.
+        * fast/replaced/encrypted-pdf-as-object-and-embed.html: Added.
+        * fast/replaced/resources/encrypted-image.pdf: Added.
+        Add a test ensuring that we don't crash with encrypted PDF in <object> or <embed>.
+
 2019-02-12  Jiewen Tan  <jiewen_tan@apple.com>
 

trunk/Source/WebKit/ChangeLog

@@ +1 @@
+2019-02-13  Tim Horton  <timothy_horton@apple.com>
+
+        Encrypted PDFs inside <embed> or <object> crash the Web Content process
+        https://bugs.webkit.org/show_bug.cgi?id=194605
+        <rdar://problem/19894818>
+
+        Reviewed by Andy Estes.
+
+        * WebProcess/Plugins/PDF/PDFPlugin.mm:
+        (WebKit::PDFPlugin::createPasswordEntryForm):
+        Don't try to create a password form field if we can't make form fields.
+
+        This means you will be left with a useless embedded PDF, but at least
+        the Web Content process won't crash.
+
+        We'll need to find an alternative implementation of PDF embedded form
+        fields that is compatible with <embed> and <object> if we want to support
+        this. Currently we piggy-back off the fact that we can just insert
+        <input>s into the PluginDocument's DOM, but we can't do that if there
+        is no PluginDocument, just a main document, like in the <embed> case.
+
 2019-02-12  Jiewen Tan  <jiewen_tan@apple.com>
 

trunk/Source/WebKit/WebProcess/Plugins/PDF/PDFPlugin.mm

@@ -1125 +1125 @@
 void PDFPlugin::createPasswordEntryForm()
 {
+    if (!supportsForms())
+        return;
+
     m_passwordField = PDFPluginPasswordField::create(m_pdfLayerController.get(), this);
     m_passwordField->attach(m_annotationContainer.get());