PDFs fail to load with Allowviews

[user394200]

We recently upgraded our application (macOS + Windows) from CEF 142 to CEF 149 and noticed that PDF files no longer render or load.
When testing with cefclient.exe using default settings (Chrome runtime), PDFs load as expected. However, the issue reproduces consistently in our application, which uses the Alloy style / views runtime.

Are there any known regressions or changes in CEF 143-149 regarding PDF extension initialization or PDFium integration under Alloy views?

[magreenblatt]

Does the issue reproduce with "cefclient --use-alloy-style --use-views" at your CEF version?

[mic]

We also have this issue with CEF 149, but in macOS, and without using Views. We cannot get a PDF to load using any technique. The extension always displays a sad face graphic. The navigation events indicate that PDFs are completely and successfully loaded. Whatever happens must happen after that, during rendering.

We cannot reproduce the issue using the CEF demo clients. However, even if it is something in our app, it only started occurring when we upgraded from CEF 142 to CEF 149. Any ideas?

[magreenblatt]

Sad face would suggest a sub-process is crashing. You can enable crash reporting or run with a debugger attached. See “Automatically attach to child processes” at https://www.chromium.org/developers/how ... n-windows/

[mic]

Between CEF 142 and 149, there must have been changes that affect the operation of PDFium or plugins generally. Nothing in the associated commits jumps out, but there must be something. Any ideas?

[magreenblatt]

You’re asking about 7 months of Chromium development, which is 40k+ commits. You will need to do some leg work with a debugger.

[mic]

Presumably, the issue description would be instrumental in narrowing the list from 40k+ to some manageable number, unless you are saying that any of those commits could be the cause. If you have no ideas on likely commits, perhaps you could recommend a debugging strategy, since all we know is that the failure occurs at some point after the PDF has been completely received, but before it is completely rendered. That is potentially quite a lengthy debugging session, and one in which none of our own code is involved.

Thanks for any help you can provide.

[mic]

As it turns out, for PDFs CEF passes a CefBrowser object to navigation events like OnLoadStart,
OnLoadEnd, etc. which returns null from CefBrowser::GetMainFrame. Trying to dereference this unexpectedly null pointer crashes the associated renderer process.

Presumably this occurs for PDFs because the main frame is now hosted in a different renderer process, and the PDF now resides in a cross-origin sub-frame. This must have happened at some point between CEF 142 and CEF 149.

[ndesktop]

PDF is hosted in a guest view. If a view is in "excluded" (see libcef/renderer/render_manager.cc's MaybeCreateBrowser) probably browser_info_ does not get a browser set AFAIK.