Changes by Marius Dumitru Florea on 14/Oct/25 18:07
Resolution:
Fixed
Status:
OpenClosed
3 comments
Marius Dumitru Florea on 14/Oct/25 18:01
Starting with XWIKI-23187 we are enforcing a timeout for the HTTP requests we make to the headless Chrome instance used to generate the PDF. The default timeout of 10s is OK for small to medium PDF exports (that take less than 1m to execute) but to low for large exports. Note that printing the HTML page to PDF is done with a single blocking request, after the HTML page is ready. Increasing the page ready timeout will give time to Chrome to load the large HTML in memory and execute the JavaScript code that generates the print layout, but the final request to print the loaded HTML to PDF is still limited by default to 10s. From my tests the time taken to print to PDF is roughly 1/6 the time taken to have the HTML page ready. Given that we expose only the page ready timeout in the PDF export administration, the users are not aware that there is another timeout that needs to be increased for large exports. I propose to use a computed value for the Chrome remote debugging timeout, based on the page ready timeout, so that users have to customize a single value most of the time. For edge cases, users can set the Chrome remote debugging timeout from xwiki.properties:
export.pdf.chromeRemoteDebuggingTimeout=10
Marius Dumitru Florea on 14/Oct/25 18:02
Starting with XWIKI-23187 we are enforcing a timeout for the HTTP requests we make to the headless Chrome instance used to generate the PDF. The default timeout of 10s is OK for small to medium PDF exports (that take less than 1m to execute) but to too low for large exports. Note that printing the HTML page to PDF is done with a single blocking request, after the HTML page is ready. Increasing the page ready timeout will give time to Chrome to load the large HTML in memory and execute the JavaScript code that generates the print layout, but the final request to print the loaded HTML to PDF is still limited by default to 10s. From my tests the time taken to print to PDF is roughly 1/6 the time taken to have the HTML page ready. Given that we expose only the page ready timeout in the PDF export administration, the users are not aware that there is another timeout that needs to be increased for large exports. I propose to use a computed value for the Chrome remote debugging timeout, based on the page ready timeout, so that users have to customize a single value most of the time. For edge cases, users can set the Chrome remote debugging timeout from {{xwiki.properties}}:
Starting with XWIKI-23187 we are enforcing a timeout for the HTTP requests we make to the headless Chrome instance used to generate the PDF. The default timeout of 10s is OK for small to medium PDF exports (that take less than 1m to execute) but too low for large exports. Note that printing the HTML page to PDF is done with a single blocking request, after the HTML page is ready. Increasing the page ready timeout will give time to Chrome to load the large HTML in memory and execute the JavaScript code that generates the print layout, but the final request to print the loaded HTML to PDF is still limited by default to 10s. From my tests the time taken to print to PDF is roughly 1/6 the time taken to have the HTML page ready. Given that we expose only the page ready timeout in the PDF export administration, the users are not aware that there is another timeout that needs to be increased for large exports. I propose to use a computed value for the default Chrome remote debugging timeout, based on the page ready timeout, so that users have to customize a single value most of the time. For edge cases, users can set the Chrome remote debugging timeout from {{xwiki.properties}}:
