Issue 649755 link

Starred by 5 users

Issue metadata

Status:	Available
Owner:	----
Cc:	█ mkwst@chromium.org
Components:	Blink>SecurityFeature Internals>Plugins>PDF
EstimatedDays:	----
NextAction:	----
OS:	Linux
Pri:	3
Type:	Bug

CSP blocking inline styles on PDF embed page.

Reported by pdk...@gmail.com, Sep 23 2016

Issue description

Chrome Version: 53.0.2785.116
OS Version: Ubuntu 14.04

https://www.ssllabs.com/downloads/SSL_TLS_Deployment_Best_Practices.pdf

The PDF renders in its own separate frame, with its own separate scrollbar.

A way to temporarily fix this is to open Developer Tools (for the page, not the separate frame), and then disable and re-enable any style on the body. This makes it snap back into the full window.

Comment 1 by thestig@chromium.org, Sep 29 2016

Components: Internals>Plugins>PDF Blink>Layout
Status: Untriaged (was: Unconfirmed)

That's weird. I don't understand how ends up with the margins though.

Comment 2 by drott@chromium.org, Oct 3 2016

Status: Available (was: Untriaged)

Comment 3 by rickyz@chromium.org, Jun 14 2017

Cc: mkwst@chromium.org
Components: -Blink>Layout Blink>SecurityFeature
Owner: sa...@chromium.org
Summary: CSP blocking inline styles on PDF embed page. (was: pdf rendered in separate frame)

Since the PDF linked in the bug is gone now, here is another one I have experienced this on recently: https://gcc.gnu.org/onlinedocs/gcc-7.1.0/gcc.pdf.

I've attached a screenshot of what it looks like - notice the double scrollbars - one for the page and one for the embed with the pdf. Interestingly, this does not happen if I download the pdf and view it from the filesystem.

Looking at the developer console, I see this error:

Refused to apply inline style because it violates the following Content Security Policy directive: "default-src 'self' http: https:". Either the 'unsafe-inline' keyword, a hash ('sha256-1kQs8h/ra9YlH+s6eZbKdSD/cn6Ljcz2Rv60pJnk/eY='), or a nonce ('nonce-...') is required to enable inline execution. Note also that 'style-src' was not explicitly set, so 'default-src' is used as a fallback.

So it looks like CSP on https://gcc.gnu.org/ is blocking the inline style on the autogenerated embed code for the PDF viewer. I wonder if there are more cases apart from the PDF viewer where we generate HTML with inline styles, etc...

A quick code search for HTMLHtmlElement::Create with setting style attributes shows up:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/ImageDocument.cpp?q=HTMLHtmlElement::create&sq=package:chromium&l=225&dr=C
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/PluginDocument.cpp?q=HTMLHtmlElement::create&sq=package:chromium&l=90&dr=C
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/html/media/MediaDocument.cpp?q=HTMLHtmlElement::create&sq=package:chromium&l=146&dr=C
at least.

Adding mkwst@, who might know more about CSP and sammc@, who touched some of this code a long time ago:
https://chromium.googlesource.com/chromium/src/+blame/7055702f4e456753783d341e73043d311fcbfa85/third_party/WebKit/Source/core/html/PluginDocument.cpp#100