Protocol error (Page.printToPDF): Target closed.

  • I Seem to be getting this error quite a lot after updating to version 2.5.0:

    Protocol error (Page.printToPDF): Target closed.
    Error: Protocol error (Page.printToPDF): Target closed. at Promise (/app/node_modules/puppeteer/lib/Connection.js:183:56) at new Promise () at CDPSession.send (/app/node_modules/puppeteer/lib/Connection.js:182:12) at Page.pdf (/app/node_modules/puppeteer/lib/Page.js:926:39) at Page. (/app/node_modules/puppeteer/lib/helper.js:111:23) at runWithTimeout (/app/node_modules/jsreport-chrome-pdf/lib/conversion.js:164:27) at at process._tickDomainCallback (internal/process/next_tick.js:229:7)

    Is there any advice to how to stop it, or what is causing it?

  • Hmm, looking again it seems to be an issue with the amount of data that I am sending to the report (and therefore the amount of pages).

    Usually I would get a timeout error if there were too many pages, but not it looks like I get this. Does that sound right?

  • administrators

    it is hard to know what can be causing that kind of issue, usually it depends on the template, but i can that chrome breaks with big html. the best will be to check the template so if you can replicate the template in the playground then we can take a look

  • Hi, I should probably emphasise that this error only arises after updating to 2.5.0

    If I run the exact same template and the exact same data in an earlier version I do not get this error.

  • Hi, just refining the question here.

    If I run the template in version 2.5.0 i get this error:

    Protocol error (Runtime.callFunctionOn): Target closed.
    Error: Protocol error (Runtime.callFunctionOn): Target closed. at Promise (/app/node_modules/puppeteer/lib/Connection.js:183:56) at new Promise () at CDPSession.send (/app/node_modules/puppeteer/lib/Connection.js:182:12) at JSHandle.jsonValue (/app/node_modules/puppeteer/lib/JSHandle.js:87:43) at JSHandle. (/app/node_modules/puppeteer/lib/helper.js:111:23) at ExecutionContext.evaluate (/app/node_modules/puppeteer/lib/ExecutionContext.js:49:33) at at process._tickDomainCallback (internal/process/next_tick.js:229:7) -- ASYNC -- at ExecutionContext. (/app/node_modules/puppeteer/lib/helper.js:110:27) at DOMWorld.evaluate (/app/node_modules/puppeteer/lib/DOMWorld.js:112:20) at at process._tickDomainCallback (internal/process/next_tick.js:229:7) -- ASYNC -- at Frame. (/app/node_modules/puppeteer/lib/helper.js:110:27) at Page.evaluate (/app/node_modules/puppeteer/lib/Page.js:782:43) at Page. (/app/node_modules/puppeteer/lib/helper.js:111:23) at runWithTimeout (/app/node_modules/chrome-page-eval/lib/eval.js:179:39) at at process._tickDomainCallback (internal/process/next_tick.js:229:7)

    +0 Starting rendering request 823 (user: reports)
    +3 Rendering template { name: excelTables, recipe: html-to-xlsx, engine: handlebars, preview: true }
    +7 Adding sample data BkxQsl9E1B
    +12 Resources not defined for this template.
    +15 Base url not specified, skipping its injection.
    +15 Rendering engine handlebars
    +35 Taking compiled template from engine cache
    +50 Executing recipe html-to-xlsx

    If I roll the server back to version 2.3.0 and run the exact same template then it works.

    Currently I am not able to use version 2.5.0 because of these errors.

  • Try to downgrade chrome/puppeteer. Maybe they have some regression bug in the newer version which is used by the jsreport 2.5.0.

    npm i puppeteer@1.11.0 

  • @jan_blaha I upgraded to 2.5.0 yesterday and very quickly discovered this issue, I just tried downgrading Puppeteer to 1.11.0 as you suggested but it makes no difference - I will have to backdate to 2.4.0 for the time being, pitty as the new editor is much better

  • Are you sure you have downgraded puppeteer successfully?
    Run the template with debug button, you should see

    Converting with chrome HeadlessChrome/72.0.3618.0 using dedicated-process strategy

    I don't think there is something in jsreport 2.5.0 that could make it failing like this except different chrome version.

  • @jan_blaha Hmm, I dont see that Chrome version, I see

    +21803 Executing recipe chrome-pdf
    +22078 Converting with chrome HeadlessChrome/73.0.3683.103 using dedicated-process strategy
    +24096 Running chrome with params {"printBackground":true,"margin":{}}
    Error: Protocol error (Page.printToPDF): Target closed.
    at Promise (/app/node_modules/puppeteer/lib/Connection.js:186:56)
    at new Promise (<anonymous>)
    at CDPSession.send (/app/node_modules/puppeteer/lib/Connection.js:185:12)
    at Page.pdf (/app/node_modules/puppeteer/lib/Page.js:911:39)
    at Page.<anonymous> (/app/node_modules/puppeteer/lib/helper.js:145:23)
    at runWithTimeout (/app/node_modules/jsreport-chrome-pdf/lib/conversion.js:164:27)
    at <anonymous>
    at process._tickDomainCallback (internal/process/next_tick.js:229:7)

    However if bash into my Docker image locally and do a

    cat node_modules/puppeteer/package.json

    it shows

    "version": "1.11.0"

    There must be more to downgrading Chrome than puppeteer - forgive me I know very little about how Chrome works with puppeteer or even what puppeteer is (perhaps I should Google that :) )


  • Ah ok, you use docker. The docker doesn't use the chrome installed through puppeteer because that one doesn't work in the headless docker environment.
    See how the chrome is installed in the 2.4.0 version

    It would help us a lot if you would prepare for us a replicable demo. We will be releasing in the next days jsreport 2.6.0 and it would be great if we can test if your issue is resolved there before we ship it.

  • @jan_blaha
    Thanks for your quick responses :)

    So we use JsReport a little differently to normal case I think, our Request Data (or sample Data) contains URLS of where to get the actual data from, the reports JS file will fetch the data and populate the context for the template to iterate over.

    However this does not seem to be the problem as I was able to reproduce the error within our Docker test environment with just a Template and a large sample Data file (2000 records) side stepping the JS file altogether, reducing the sample Data to 1000 records and it runs fine - I have not found the breaking point

    But when I copied these 2 files to the JsReport Playground I was unable to make it error, it produced an 86 page document (which is not huge I would think)

    I have checked the Azure Webapp to make sure its not barfing on memory and its not, the VM is not huge but the memory graph shows its sits well under 10% usage always.

    The following Dropbox link has the Template and Sample Data, although I doubt its of much use since the Playground renders it fine PDF Protocol

    Below is our straight forward Docker file, from 2.5.0 it installs a config override + a few extra NPM modules and our helper Node module - the Puppeteer downgrade to 1.11.0 also shown

    FROM jsreport/jsreport:2.5.0-full AS prod

    COPY jsreport.config.json /jsreport/jsreport.config.json

    WORKDIR /app
    RUN npm i

    COPY node_modules/virtualmgr /app/node_modules/virtualmgr

    and the jsreport.config.json which essentially overrides some timeouts (this is not a timeout issue though)

    "httpPort": 5488,
    "allowLocalFilesAccess": true,
    "store": {
    "provider": "fs"
    "blobStorage": {
    "provider": "fs"
    "templatingEngines": {
    "timeout": 600000
    "chrome": {
    "timeout": 600000
    "extensions": {
    "scripts": {
    "timeout": 600000
    "html-to-xlsx": {
    "timeout": 600000

    I also tried using the Dockerfile from 2.4.0 as my "FROM" which built ok (and should have used Chromium 64 with latest NPM JsReport) but when I run it it errors with

    2019-08-19T14:51:52.991144204Z 2019-08-19T14:51:52.915Z - info: Initializing jsreport@2.5.0 in production mode using configuration file: jsreport.config.json
    2019-08-19T14:51:52.991177604Z 2019-08-19T14:51:52.924Z - info: Searching for available extensions in /app/
    2019-08-19T14:51:52.991183504Z 2019-08-19T14:51:52.977Z - info: Extensions location cache not found, crawling directories
    2019-08-19T14:51:57.726926059Z 2019-08-19T14:51:57.495Z - info: Found 31 extensions
    2019-08-19T14:51:57.731570662Z 2019-08-19T14:51:57.686Z - error: Error occured during reporter init Error: options contain values that does not match the defined full root schema. schema validation errors: should be equal to one of the allowed values. allowed values: ["memory", "fs"]
    2019-08-19T14:51:57.731588562Z at Reporter.init (/app/node_modules/jsreport-core/lib/reporter.js:141:15)
    2019-08-19T14:51:57.731594162Z Error: options contain values that does not match the defined full root schema. schema validation errors: should be equal to one of the allowed values. allowed values: ["memory", "fs"]
    2019-08-19T14:51:57.731599162Z at Reporter.init (/app/node_modules/jsreport-core/lib/reporter.js:141:15)

    this appears to be something to do with my Azure environment variable of

    "name": "store_provider",
    "value": "mongodb",

    which should be fine as this hasn't changed and surely mongodb is still supported ?

  • We use docker as well.

    We cannot move past version 2.4.0.

    Our entire setup works using 2.4.0, but the minute that we update to 2.5.0 we get these errors.

    I am not sure how we can make a replicable demo to show you. It can't be replicated in the playground.

  • @stevef51 I tried your export uploaded to dropbox and it works for me on image 2.5.0-full. I even multiplied the input data and it renders 766 pages pdf without errors. Can you try to run just the official image jsreport/jsreport:2.5.0 without any config. Upload there export you shared and run the template. Does it break for you?

    @AB-D It would help if you upload somewhere or email me jsreport export which is failing for you.

  • @jan_blaha
    This is weird, so I changed our Azure Webapp to use "jsreport/jsreport:2.5.0-full" as you suggested and removed all custom configuration (so removed MongoDb storage etc) - it still errors with that basic 2000 record report. However running the same Docker image locally with no custom configuration (so should be exactly same as the Azure Webapp) and it runs just fine, tested up to 511 pages without an issue.

    Jan, Are you able to test on an Azure Webapp ?

  • @jan_blaha
    Ok, its something to do with 2.5.0 and Azure Webapp - I just updated the Azure Webapp to use my hacked "2.5.0 with Chromium 64" image which is the Docker file from 2.4.0 which NPM fetches latest JsReport - and this works fine, this image however does not include the MongoDb extension (+ a bunch of other extensions) since it logs only 31 extensions found at startup whilst the "-full" images find 49 extensions

  • Yes, I confirm the behavior. It crashed on the azure web app but locally it works. We will test it with the docker image that we will ship in a few days with jsreport 2.6.0 and come back here.

  • I fixed the error "Protocol error (Page.printToPDF): Target closed." replacing 'chrome-pdf' with 'phantom-pdf'

  • Hi probably doesn't help you but I just had the same issue and downgraded to 2.4.0 to fix it. Keen to know when 2.6.0 is ready so I can test it.

  • @odirleiborgert yeah, I know that is kindof a work around but I find most reports render better with ChromePDF, although there are some instances where PhantomPDF does a better job due to rendering glitches in ChromePDF

  • Hi @jan_blaha do you have any update on this issue and version 2.6.0?

Log in to reply

Looks like your connection to jsreport forum was lost, please wait while we try to reconnect.