Bug 114938

Summary: PDFPlugin: Support unlocking encrypted PDFs
Product: WebKit Reporter: Tim Horton <thorton>
Component: PDFAssignee: Tim Horton <thorton>
Status: RESOLVED FIXED    
Severity: Normal CC: ap, mitz, simon.fraser
Priority: P2 Keywords: InRadar
Version: 528+ (Nightly build)   
Hardware: Unspecified   
OS: Unspecified   
Attachments:
Description Flags
patch
oliver: review+
patch ap: review+

Description Tim Horton 2013-04-22 01:24:34 PDT
<rdar://problem/12872888>
Comment 1 Tim Horton 2013-04-22 01:45:31 PDT
Created attachment 199002 [details]
patch
Comment 2 Alexey Proskuryakov 2013-04-22 10:23:55 PDT
Comment on attachment 199002 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=199002&action=review

> Source/WebKit2/ChangeLog:30
> +        Try to unlock the PDF with the given password. If this succeeds, remove
> +        the password field and relayout the scroll view.

Is there any feedback when the password is incorrect?

> Source/WebKit2/WebProcess/Plugins/PDF/PDFPlugin.mm:96
> +"    -webkit-text-security: disc;"

Does this actually enable secure text input, or do we need an <input type=password> for that?

> Source/WebKit2/WebProcess/Plugins/PDF/PDFPlugin.mm:352
> +        m_passwordField = 0;

nullptr

> Source/WebKit2/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.h:49
> +    virtual bool handleEvent(WebCore::Event*) OVERRIDE;

I'm a bit suspicious of the many public handleEvent functions in this patch. Most of the time, I expect functions with OVERRIDE to be private.

> Source/WebKit2/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.h:58
> +    WTF::String value() const;

s/WTF:://

> Source/WebKit2/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.mm:100
> +    if (textAnnotation) {

Can this be an early return instead?

> Source/WebKit2/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.mm:125
> +    this->textAnnotation().stringValue = value();

I don't this that you need "this->" here any more.
Comment 3 Tim Horton 2013-04-22 10:25:52 PDT
(In reply to comment #2)
> (From update of attachment 199002 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=199002&action=review
> 
> > Source/WebKit2/ChangeLog:30
> > +        Try to unlock the PDF with the given password. If this succeeds, remove
> > +        the password field and relayout the scroll view.
> 
> Is there any feedback when the password is incorrect?

Yes, but it's underneath us.

> > Source/WebKit2/WebProcess/Plugins/PDF/PDFPlugin.mm:96
> > +"    -webkit-text-security: disc;"
> 
> Does this actually enable secure text input, or do we need an <input type=password> for that?

I... don't know! I'll find out.

> > Source/WebKit2/WebProcess/Plugins/PDF/PDFPlugin.mm:352
> > +        m_passwordField = 0;
> 
> nullptr

Oooh la la.

> > Source/WebKit2/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.h:49
> > +    virtual bool handleEvent(WebCore::Event*) OVERRIDE;
> 
> I'm a bit suspicious of the many public handleEvent functions in this patch. Most of the time, I expect functions with OVERRIDE to be private.

Err, yeah, you're right.

> > Source/WebKit2/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.h:58
> > +    WTF::String value() const;
> 
> s/WTF:://
>
> > Source/WebKit2/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.mm:100
> > +    if (textAnnotation) {
> 
> Can this be an early return instead?
> 
> > Source/WebKit2/WebProcess/Plugins/PDF/PDFPluginTextAnnotation.mm:125
> > +    this->textAnnotation().stringValue = value();
> 
> I don't this that you need "this->" here any more.

Quite.
Comment 4 Tim Horton 2013-04-22 10:30:25 PDT
(In reply to comment #3)
> (In reply to comment #2)
> > > Source/WebKit2/WebProcess/Plugins/PDF/PDFPlugin.mm:96
> > > +"    -webkit-text-security: disc;"
> > 
> > Does this actually enable secure text input, or do we need an <input type=password> for that?
> 
> I... don't know! I'll find out.

Looks like not, so I'll override createAnnotationElement() as well and make an <input type=password>.
Comment 5 Alexey Proskuryakov 2013-04-22 10:40:29 PDT
Maybe we should fix -webkit-text-security instead (and not necessarily right now).
Comment 6 Tim Horton 2013-04-22 12:00:24 PDT
(In reply to comment #5)
> Maybe we should fix -webkit-text-security instead (and not necessarily right now).

Filed https://bugs.webkit.org/show_bug.cgi?id=114979 about that but I'm not planning on working on it.
Comment 7 Tim Horton 2013-04-22 14:00:24 PDT
Created attachment 199106 [details]
patch
Comment 8 Alexey Proskuryakov 2013-04-22 14:06:22 PDT
Comment on attachment 199106 [details]
patch

View in context: https://bugs.webkit.org/attachment.cgi?id=199106&action=review

> Source/WebKit2/WebProcess/Plugins/PDF/PDFPluginPasswordField.mm:28
> +#if ENABLE(PDFKIT_PLUGIN)
> +
> +#import "config.h"

I think that ENABLE macros won't work before config.h.

> Source/WebKit2/WebProcess/Plugins/PDF/PDFPluginPasswordField.mm:43
> +using namespace WebCore;
> +
> +namespace WebKit {
> +
> +using namespace HTMLNames;

Funny that using declarations are in different places.
Comment 9 Alexey Proskuryakov 2013-04-22 14:07:25 PDT
s/declarations/directives/
Comment 10 Tim Horton 2013-04-22 14:09:20 PDT
(In reply to comment #8)
> (From update of attachment 199106 [details])
> View in context: https://bugs.webkit.org/attachment.cgi?id=199106&action=review
> 
> > Source/WebKit2/WebProcess/Plugins/PDF/PDFPluginPasswordField.mm:28
> > +#if ENABLE(PDFKIT_PLUGIN)
> > +
> > +#import "config.h"
> 
> I think that ENABLE macros won't work before config.h.

And yet they do. Will move it.

> > Source/WebKit2/WebProcess/Plugins/PDF/PDFPluginPasswordField.mm:43
> > +using namespace WebCore;
> > +
> > +namespace WebKit {
> > +
> > +using namespace HTMLNames;
> 
> Funny that using declarations are in different places.

Oops!

Thanks!
Comment 11 Tim Horton 2013-04-22 14:18:26 PDT
https://trac.webkit.org/changeset/148912