Pagedown: output.html does not render in google chrome or chromium, but works in firefox

[brentthorne]

Not sure if this is the case for other people as well but html_paged and jss_paged output.html files do not open in google chrome or in chromium; however, they work well in firefox :confused:

The html_poster template works fine in all posters though. Also all of the posterdown html output options work fine but they use the html_poster not html_paged as their base.

Just thought I would let you guys know :smiley_cat:. Here's my current set up:

chrome

google chrome build - Version 74.0.3729.157 (Official Build) (64-bit)

R

R version 3.6.0 (2019-04-26)
Platform: x86_64-pc-linux-gnu (64-bit)
Running under: Arch Linux

pagedown 0.2.5

Cheers!

[RLesur]

Right now, I am working on documents built on top of html_paged and all work well for me.
During the last days, I've worked on different environments: windows 7, Ubuntu and docker containers (debian testing). In all these environments, I was able to produce pdf with the last chrome stable.

In order to test your config, could you run the following commands:

pagedown::chrome_print("https://pagedown.rbind.io", "html_paged.pdf")
pagedown::chrome_print("https://pagedown.rbind.io/jss-paged", "jss_paged.pdf")

Do you get two pdf files?
Are they correct?

If the pdf are not correct, please send us the log of this script:

pagedown::chrome_print("https://pagedown.rbind.io", "html_paged.pdf", verbose = 2)
pagedown::chrome_print("https://pagedown.rbind.io/jss-paged", "jss_paged.pdf", verbose = 2)

[brentthorne]

The pdf file I get are correct on my main machine as well as when I test on windows 10. However, the issue is not really the chrome print functionality, it is the ability to view the output.html in the chrome web browser itself.

I have now tested both my fork as well as this repo of pagedown and the behaviour is the same. The Rmd will knit without any issues, but when opening the output.html file in the chrome browser the document begins to load (without the paged.js styling) and then goes blank. However, if I use xaringan::inf_mr() the document does indeed become 'paged' and works as expected in the chrome browser.

The odd part to this is that when opening the output.html in firefox there are no issues. Again I have now tried this and replicated the issue on Ubuntu 18.04, Arch, as well as Windows 10 and Windows 10 Pro using R 3.5 and R 3.6.

[RLesur]

Thanks, this is very useful!

My guess is that you tried to open the output.html file without using a local web server.
In other words, in the address bar, I think you have file://.../output.html instead of http://localhost.../output.html
If I am right, I think you get in the Chrome console a message like this one "Cross origin requests are only supported for HTTP."

Tell me if am wrong.

[cderv]

I can also reproduce and already has encountered this. I can confirm that Firefox has not this security mesure and can correctly open the file. Chrome is blocking not http:// or https:// url and ressources links.

Useful R function to serve the file are also servr::http() or servr::httpw(). xaringan::inf_mr() does that with more features.

I think you can use a flag to deactivate this security (for dev purposes only obviously) : --disable-web-security. Unfortunately, it don't work well on windows.

@RLesur, we may document more clearly somewhere as this is a know issue / happening thing. what do you think ?

[brentthorne]

I am curious as to why it is happening for the html_paged or any output that is based off of it but does _not_ happen with the html_poster output.

@cderv have you tried the html_poster option yet? Are you able to view it in chrome as expected? If so do you have any thoughts as to why it would work compared to html_paged ?

[RLesur]

I am curious as to why it is happening for the html_paged or any output that is based off of it but does _not_ happen with the html_poster output.

The message in the Chrome console looks like this one:

Access to XMLHttpRequest at 'file:///C:/.../paged-0.2.6/css/default-fonts.css' from origin 'null' has been blocked by CORS policy: Cross origin requests are only supported for protocol schemes: http, data, chrome, chrome-extension, https.

That means Paged.js uses AJAX to open and analyze the CSS files. The AJAX requests are blocked by Chrome because of its security settings.

The html_poster output format does not use Paged.js: there is no AJAX request. That is why it works in Chrome without a local web server.

This behavior was quickly mentionned by @yihui in his talk at rstudio::conf2019: this is the "complicated reasons" in https://bit.ly/pagedown#9

@cderv Sure, the documentation can be improved! However I don't know how to explain with common words that Paged.js uses AJAX requests that are (legitimately) blocked by Chrome if the user does not use a local web server. Here, FF has lower security settings that can be used to attack the user. IMO Chrome should not be blamed since the behavior is explained by FF security settings that do not sufficiently protect the user. Have you a proposal?

[cderv]

Paged.js uses AJAX requests that are (legitimately) blocked by Chrome if the user does not use a local web server. Here, FF has lower security settings that can be used to attack the user. IMO Chrome should not be blamed since the behavior is explained by FF security settings that do not sufficiently protect the user.

This is just fine ! 😄

I believe something is better that nothing. So I was thinking of just advicing to use xaringan::inf_mr() or servr::httd() when using some paged.js format to be sure it shows ok.

[yihui]

I think I had documented it last year: https://github.com/rstudio/pagedown/commit/38494d9cdd9d3e5c45a550d19bf84a5b8d96cf3a#diff-53d905968d17f5efb2282302b2f831ecR48

[daattali]

I may be misunderstanding the issue, but setting self_contained: true seems to fixed the issue for me and now I can open html_paged pages in chrome

[RLesur]

@daattali You're right: the issue arises only for non self contained documents opened without a local webserver. Using self_contained: true or a local webserver works fine.