Just a question:
Must the docker image for the chrome headless browser and XWiki itself run on the same machine?
Our XWiki server uses a FreeBSD system and there is a problem to run docker on this operating system.
After some code inspection I have the impression that the chrome manager relies on being able to start the docker image itself.
Any help is greatly appreciated.
Thanks
Norbert
Hi Norbert. Does https://extensions.xwiki.org/xwiki/bin/view/Extension/PDF%20Export%20Application/#HPDFGenerator contain the info you need?
Just configure the PDF export to use a remote Chrome instance. It’s up to you how you run that Chrome instance (inside a Docker container or not, on the same machine as XWiki or not). But the remote Chrome instance needs to be able to access (i.e. load pages from) the XWiki instance.
oops - if you can read, you have a clear advantage, especially if you read the right texts.
Thanks
Norbert
I have a configurd remote chrome instance inside a docker instance on a different machine.
The test if pdf printer is available is successful, but printing does not work.
The Wiki server can be accessed from the docker container (tested successfully be wget).
May be the problem is caused by access rights within our non public wiki, as all wiki pages need a user login.
Will the user specific and validation cookies (language, username, password, validation) be transferred to the remote chrome?
Norbert
The cookies are transferred to the remote Chrome, so it should work normally if you use the standard authentication method. If you use a custom authenticator on top of XWiki, then you need to see how the authentication is performed. If it is using cookies then it should work (unless it also checks the IP address). If it uses some custom HTTP headers then it probably doesn’t work.
Some additional remarks of the current (not working) situation:
XWiki is running on a machine with a FreeBSD operating system which does not support docker.
A different Debian machine runs a Docker instance ( zenika/apline-chrome) with the following start command:
docker run -d -p 9222:9222 zenika/alpine-chrome --no-sandbox
\ --remote-debugging-address=0.0.0.0 --remote-debugging-port=9222
\ --disable-web-security --disable-gpu --remote-allow-origins=*
\ --headless=old --run-compistor-stages-before-draw
\ --disable-dev-shm-usage --window-size=1920,18000
The additional parameters are due to the fact that I have verified the functionality of the installation with a node test program.
–disable-gpu - without this, chrome will not run on this machine anyway
–disable-dev-shm-usage is due to the fact that without this parameter chrome crashes on certain web pages.
The two parameters are set
due the fact that some web pages load pictures after scroll to the position. To avoid scrolling within the program I use a very large window and all pictures are loaded from the beginning.
The value 18000 is a quick shot. May be there are web pages with a unlimited “papyrus like” design.
(–run-compistor-stages-before-draw was a trial and is still left.)
The test program uses Chrome DevTools Protocol commands natively and communicates using a web socket and initiates a “Page.printToPDF” when network traffic has finished (use of “Network.enable”)
summarized:
I have a running “chrome-print-to-pdf”-Server
The server can connect to XWiki (tested by generating PDF of the XWIki login page)
The server is recognized by XWiki when configurating PDF output.
But
PDF export starts and stops with an popup error message “Export als PDF fehlgeschlagen” (german XWiki)
The used account is a local XWiki account (user/password only)
The error message in catalina.out:
2024-06-18 11:15:17,880 [pool-19-thread-4] ERROR g.k.c.s.i.WebSocketServiceImpl - Failed sending data to ws server ws://134.147.111.6:9222/devtools/browser/e02885eb-6dc0-45b6-8f19-954ba728006f...
java.lang.IllegalStateException: The connection has been closed.
at org.glassfish.tyrus.core.TyrusSession.checkConnectionState(TyrusSession.java:530)
at org.glassfish.tyrus.core.TyrusSession.getBasicRemote(TyrusSession.java:212)
at com.github.kklisura.cdt.services.impl.WebSocketServiceImpl.send(WebSocketServiceImpl.java:128)
at com.github.kklisura.cdt.services.impl.ChromeDevToolsServiceImpl.invoke(ChromeDevToolsServiceImpl.java:142)
at com.github.kklisura.cdt.services.invocation.CommandInvocationHandler.invoke(CommandInvocationHandler.java:87)
at com.sun.proxy.$Proxy175.getVersion(Unknown Source)
at org.xwiki.export.pdf.internal.chrome.ChromeManager.lambda$isConnected$0(ChromeManager.java:129)
at java.base/java.util.concurrent.FutureTask.run(FutureTask.java:264)
at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
at java.base/java.lang.Thread.run(Thread.java:829)
It looks like the web-socket communication between XWiki and Chrome does not work (why?) although http-Request work (“/json/list”) is successful (when testing if the server is working)
Any ideas for further testing / investigations ?
Thanks
Norbert
What version of zenika/apline-chrome are you using? Maybe there’s an incompatibility between the Chrome version and the version of GitHub - kklisura/chrome-devtools-java-client: Chrome DevTools java client. (we’re using the latest 4.0.0). Otherwise, I’d check how to enable debug logs on the Chrome side and see what happens when XWiki tries to connect. Maybe it logs an error or something to explain why it doesn’t accept the connection (because from the XWiki side it appears as if Chrome closes the connection).
docker container inspect … shows
"Labels": {
"org.opencontainers.image.created": "2023-12-28T04:28:33.882Z",
"org.opencontainers.image.description": "Chrome Headless docker images built upon alpine official image",
"org.opencontainers.image.documentation": "https://github.com/Zenika/alpine-chrome/blob/master/README",
"org.opencontainers.image.licenses": "Apache-2.0",
"org.opencontainers.image.revision": "954a742aba550a21f005c02d32c9328fd38e96ae",
"org.opencontainers.image.source": "https://github.com/Zenika/alpine-chrome",
"org.opencontainers.image.title": "alpine-chrome",
"org.opencontainers.image.url": "https://github.com/Zenika/alpine-chrome",
"org.opencontainers.image.vendor": "Zenika",
"org.opencontainers.image.version": "latest"
}
See xwiki-platform/xwiki-platform-core/xwiki-platform-export/xwiki-platform-export-pdf/xwiki-platform-export-pdf-default/src/main/java/org/xwiki/export/pdf/internal/DefaultPDFExportConfiguration.java at master · xwiki/xwiki-platform · GitHub . Can you try with 115 instead of latest?
I have switch to version 115.
At the first glance there was no change.
But after (some investigations howtov …) activating a chromium log I got a lot additional news, good and bad ones:
The good news:
The communication betweeen XWiki and Chromium within the docker instance is working!
I found one simple document - just containing a “{{children /}}” which could be exporteded successfully.
Bad:
Other documents even a new document with the same content (“{{cildren /}}” does not work.
The chromium log does not show any communication error - it just stops.
IIt shows a lot of “NotifyBeforeURLRequest” for http request to be initiated (css, ssx, woff …) but it stops rather fast (1-2 seconds). The XWiki shows “Export als PDF fehlgeschlagen”.
(Just forgot to mention: We are using XWiki 14.10.20 as test version, production system is 13.10.11.
Version upgrades have be delayed until PDF export is working)
Norbert
This seems to suggest that there is a problem with Chrome, or rather that you need to tweak its parameters. Note that one of the reasons we’re not using the latest version of the Chrome Docker container is Chrome fails to load web page and crashes due to net::ERR_INSUFFICIENT_RESOURCES · Issue #222 · Zenika/alpine-chrome · GitHub . Basically when I tried with a newer version the browser was crashing, which seems to be similar to what you’re experiencing with 115. I suspect there is a way to configure Chrome to not break on PDF export, but I don’t know exactly which flags to use 
Thanks,
Marius
I did a lot of investigations:
I suspect there is a problem with the “glyphicons halflings fonts”.
The indications are:
But this is only a suspicion.
I am still searching for workarounds.
Any hints are welcome.
Norbert