Print Preview still does not load for some websites

[jasminjasmin2]

Print preview does not work in cefclient 127 and the ''Loading preview.." message never disappears when trying to print https://www.corriere.it/ website but it works for other websites.

Programmatically, in custom windowsless applications calling the PrintToPDF() function, the OnPdfPrintFinished() callback is never called and the printer process never finishes.

To Reproduce
Steps to reproduce the behavior:

1. Launch cefclient.exe --use-alloy-style --enable-print-preview --disable-features=PrintCompositorLPAC
2. Load https://www.corriere.it/ website in cefclient
3. Select Print from menu
4. Print Preview never finishes loading

Versions (please complete the following information):

• Windows 10, 11
• CEF Version: 127.3.1

Additional context

In the case of some other websites, like www.gsp.ro, when trying to print to pdf in custom windows-less applications, setting the browser window rectangle to a quite large height, like 25,000 pixels, also makes the printer process to hang. Not sure if the issues are related. Setting a large browser window for such websites is necessary if the resources loading is triggered only for elements inside the viewport.

The issue does not reproduce with Chrome 127.0.6533.99

[jasminjasmin2]

The issue is still reproducible with the latest build and it affects websites printing. Do you have any idea how to fix this or is it possible to add a switch to re-enable the old alloy runtime and style to work as it did before 125, at least until the issue is properly fixed in a future version?

[jasminjasmin2]

I tried to debug this in a third party application and a difference I could notice between the cases when it works and it not works is that after the browser is stopped while waiting for printing to PDF to finish the following error is thrown:

[0818/120745.703:ERROR:print_util.cc(40)] PrintToPDF failed with error: Printing failed
[0818/120745.703:FATAL:pdf_print_callback_ctocpp.cc(34)] Check failed: !path.empty().

The output path is set in code and it actually the same code works for other websites. I don't know why that path is not getting to printing process.

[jasminjasmin2]

What should be done to fix this issue? Could you please help? I don't understand how the output path can get empty in printer process. I tried both with sandbox and no-sandbox, debug and release builds. It is not a Chromium issue and only someone with a deep understanding of CEF code and advanced debugging skills could find the root cause of this and provide a fix. I could not find any switch recently added in Chromium which might change the behavior.

[pwerner2100]

Unfortunately this regresion seems to persist in the latest 129 release. It could be reproduced with the web pages from report and with many other websites I have tried. Off-screen printing to PDF, which should be an important feature from project description, cannot be reliably used after you made the alloy related changes. Do you have any plan to investigate and fix this in 129 or a in a future release of the project?

[jasminjasmin2]

Could you please clarify if windowless rendering will be further supported in CEF? Currently the PrintToPDF() calls hangs with many websites as soon as the windowless rendering is enabled.
The Alloy runtime was already removed. Do you intend to do the same with Alloy style which would also remove the off-screen rendering since the Alloy style is implicitly used by off-screen rendering?
I've seen the issue #3293 refers to use Ozone for off-screen rendering, but it looks like a very long term and complex task. Isn't possible to bring back the old Alloy functionality which was supporting great the off-screen rendering, even if you will mark it as deprecated?

[mbragg12]

@magreenblatt Do you know what the status of this issue is? I assume it is an actual defect and not something that is unsupported. Similar to the initial report, tinkering with 128 and --use-alloy-style, I can print simple sites like google but on large/complex sites PrintToPdf hangs.

Not sure it helps at all but if you navigate away from the site being printed, the DCHECK(!path.empty()); in OnPdfPrintFinished in pdf_print_callback_ctocpp.cc gets hit. The top of the stack for that is:

	libcef.dll!CefPdfPrintCallbackCToCpp::OnPdfPrintFinished(const CefStringBase<CefStringTraitsUTF16> & path, bool ok) Line 35	C++
 	libcef.dll!print_util::`anonymous namespace'::OnPDFCreated(const CefStringBase<CefStringTraitsUTF16> & path, scoped_refptr<CefPdfPrintCallback> callback, print_to_pdf::PdfPrintResult print_result, scoped_refptr<base::RefCountedMemory> data) Line 42	C++
 	libcef.dll!base::OnceCallback<void (int, scoped_refptr<net::IOBuffer>)>::Run(int args, scoped_refptr<net::IOBuffer> args) Line 156	C++
 	[Inline Frame] libcef.dll!print_to_pdf::PdfPrintJob::FailJob(print_to_pdf::PdfPrintResult result) Line 145	C++
 	libcef.dll!print_to_pdf::PdfPrintJob::RenderFrameDeleted(content::RenderFrameHost * render_frame_host) Line 155	C++
 	libcef.dll!content::WebContentsImpl::WebContentsObserverList::NotifyObservers<void (content::WebContentsObserver::*)(content::RenderFrameHost *),content::RenderFrameHostImpl *>(void(content::WebContentsObserver::*)(content::RenderFrameHost *) func, content::RenderFrameHostImpl * && args) Line 1678	C++
 	libcef.dll!content::WebContentsImpl::RenderFrameDeleted(content::RenderFrameHostImpl * render_frame_host) Line 7895	C++
 	libcef.dll!content::RenderFrameHostImpl::~RenderFrameHostImpl() Line 2153	C++

[jasminjasmin2]

This issues is still reproducible in the latest build. Almost two months passed since the initial report.
@magreenblatt : Could you please clarify if there is any plan to fix this critical issue with off-screen printing in the future releases or the functionality will be removed ? In the current status is practically unusable and without your great expertise I don't think somebody else can fix it.

[jasminjasmin2]

The same issue occurs when using the 'Page.printToPDF' method from DevTools protocol. The method closure callback is never invoked. If the windowsless rendering is disabled, the callback is invoked.
The 'Page.captureScreenshot' method works properly instead, so it's only a problem with printing to PDF method.
Could you guide on how to debug this?

[edgardogho]

I had this issue on linux with PrintToPDF not completing for some sites (specially the ones with google ads). The work around I found is described here:
https://www.magpcss.org/ceforum/viewtopic.php?f=6&t=19827&start=10
The /components/services/print_compositor/print_compositor_impl.cc on seems to wait for ever in a part of the code, I simply skipped the whole thing as a workaround. There will be parts that will not render (the ones that hang) but the rest will render fine on the PDF.
I get the same problem now on 129. I applied the same workaround and worked fine.

[mbragg12]

That definitely seems to be the issue. I added some logs on the IsReadyToComposite and if that returns false, the print "hangs". Now to decide what to do with this information.

[mbragg12]

edgardogho's work around definitely improves the situation (thanks for that) but there are still issues. It seems to consistently create the PDF. The PDF is usually wrong, missing images and such. The completion callback also doesn't always get called. In the case of the print preview, it shows an error saying the preview failed.

[jasminjasmin2]

Yes, I can also confirm the workaround allows the print to PDF to finish even if with missing elements. Thanks @edgardogho for this. It is not clear yet why it works (without any change) when the windowsless rendering is disabled. It seems that Alloy style still plays a role in this issue and it needs further investigation for a complete fix.