Renderer Termination on Unresolvable URLs

[aleitner]

I've recently encountered an issue with CEF/Chromium version 126.2.6+gc7c4ac9+chromium-126.0.6478.115. After updating to this version from 119, I've noticed a change in behavior when navigating to a URL that does not resolve to an address. Specifically, the renderer is terminating with the following error message:

Code: Select all

[0628/101804.448392:ERROR:bad_message.cc(29)] Terminating renderer for bad IPC message, reason 1

In our implementation, we use cef_load_handler_->on_load_error to capture load errors and write a custom error page to the document. Previously, this approach worked well, with the renderer displaying the custom error page as expected. However, post-update, although the error page is still written to the document, the renderer terminates immediately afterward, preventing any new on paint events from showing the error page we wrote to the document.

Additionally, I noticed that the C# library CefSharp handles errors in a similar manner within the load_handler (as documented here). This leads me to wonder if this functionality is now broken within the C# library as well due to the update.

[magreenblatt]

How are you navigating to the custom error page?

[aleitner]

How are you navigating to the custom error page?

We'll call load_url with a url that doesn't resolve to an address such as http://fakeurl

Code: Select all

    cef_frame_t* main_frame = browser->get_main_frame(browser);
    main_frame->load_url(main_frame, &url);

This will result in load_handler->on_load_error being called with the error_code ERR_NAME_NOT_RESOLVED.
Within this function we would call execute_java_script to execute document.write() with our error page html.

This was working until a recent update to cef/chromium

[aleitner]

I went through the spotify releases and found the exact version when this stopped working

03/15/2024 - 122.1.13+gde5b724+chromium-122.0.6261.130 / Chromium 122.0.6261.130 Worked ✅
03/28/2024 - 123.0.7+g6a21509+chromium-123.0.6312.46 / Chromium 123.0.6312.46 Stopped Working ❌

[ndesktop]

You can use a custom scheme, like is tests:// in cefclient, and return whatever HTTP body from there.

[aleitner]

You can use a custom scheme, like is tests:// in cefclient, and return whatever HTTP body from there.

While I appreciate the suggestion of using a custom scheme, such as tests://, to handle error pages by returning a specific HTTP body, this approach introduces complications that I'd prefer to avoid. Implementing redirection for error handling complicates the navigation experience, especially when users attempt to navigate backward to a previously visited page.

For instance, if a user navigates to http://notarealurl and the on_load_error callback triggers a load operation for a custom URL like error://oops, this approach presents a couple of significant issues:

1. Whitelist Complications: Introducing a custom scheme requires updating the whitelist code to allow these custom schemes. This change could inadvertently introduce new problems and complexities that are best avoided.

2. Navigation Loop: Navigating back from the error page would lead the user back to http://notarealurl, which would then redirect again to error://oops. To circumvent this, I would need to implement a custom navigation system around CEF's existing navigation capabilities, which is not a feasible solution.

I'd like to understand whether the change in renderer behavior was an intentional change or a bug. In contrast, Chromium itself manages to display error pages without terminating the renderer, suggesting that there should be a way to achieve similar functionality within CEF without resorting to workarounds that compromise the navigation experience.

[magreenblatt]

See https://www.magpcss.org/ceforum/viewtop ... =6&t=18881 for related discussion.

[aleitner]

See viewtopic.php?f=6&t=18881 for related discussion.

After reviewing the options, it seems using interstitial pages isn't viable in CEF, and it appears that utilizing the DevTools protocol as suggested by amaitland essentially mirrors my current approach without addressing the main issue. If I were to implement functionality using the devtools protocol rather than writing to the document by executing javascript the capi would need some changes as I mentioned in another forum post. I wanted to know if you believe this warrants a bug report, and if so, how to proceed with filing it?

[magreenblatt]

I wanted to know if you believe this warrants a bug report

I don't think so. Chromium uses browser-side navigation and there is no guarantee of a renderer process in cases where navigation fails. We don't support a LoadString method for the same reason.

[aleitner]

I wanted to know if you believe this warrants a bug report

I don't think so. Chromium uses browser-side navigation and there is no guarantee of a renderer process in cases where navigation fails. We don't support a LoadString method for the same reason.

Considering the now potential absence of a renderer process, the C# CEF library's use of DevTools to manipulate page content still interests me. Could you clarify how using DevTools functions like Page.getFrameTree and Page.setDocumentContent to set document HTML from the on_load_error callback differs from directly writing to the document using execute_javascript with document.write()?

I'm curious if this method circumvents the limitations we face with renderer processes during navigation failures and if it's a viable alternative for our current use case. I don't want to spend time trying to implement this if it will encounter the same issue.