LoadString results in Terminating renderer for bad IPC message, reason 205

Issue #2586 resolved
Michael Bragg created an issue

###What steps will reproduce the problem?###

make call to loadstring

###What is the expected output? What do you see instead?###

CEF Browser displays html passed into loadstring. Instead you get a blank white page.

###What version of the product are you using? On what operating system?###

Cef 3.3626.1882.g8926126 and 3.3578.1863.gbf8cff2 on Windows 32 bit

###Does the problem reproduce with the cefclient or cefsimple sample application at the same version? How about with a newer or older version?###

Can be reproduced with cefsimple in CEF 71. It was not reproducible with CEF 69.

###Does the problem reproduce with Google Chrome at the same version? How about with a newer or older version?###

No

###Description###

The loadstring call is causing a crash in the renderer process. When load string is called you will get a blank white screen and in the log you will see: [0207/164600.108:ERROR:bad_message.cc(27)] Terminating renderer for bad IPC message, reason 205

The simplest way to see this is to run: cefsimple.exe --url=http://10.255.255.1/ This will cause ERR_CONNECTION_TIMED_OUT and cefsimple will attempt to display an error page using loadstring https://bitbucket.org/chromiumembedded/cef/src/84a5749f9fd237306b8860144dfe22323999defe/tests/cefsimple/simple_handler.cc?at=master#lines-115

Looks to correlate with this discussion: https://magpcss.org/ceforum/viewtopic.php?f=6&t=16448

I can also reproduce with CefSharp. Also looks to be an issue with Java-Cef: https://bitbucket.org/chromiumembedded/java-cef/issues/319/terminating-renderer-for-bad-ipc-message

Comments (31)

  1. Marshall Greenblatt

    Thanks for the detailed bug report. LoadString (and LoadRequest) can't be used if there isn't already an existing renderer process with at least 1 successful navigation. This is related to issue #579. Note that the renderer process is not actually crashing -- the browser process is intentionally terminating it. "Reason 205" equates to RFH_ERROR_PROCESS_NON_ERROR_COMMIT.

  2. Michael Bragg reporter

    I do not believe LoadURL has the same issue. There is very similar logic in cefclient that uses LoadURL and it works.

  3. Edgardo Gho

    Does this means we can't use LoadString anymore? If that is the case, can we accomplish the same thing using LoadURL with Data URL protocol?

  4. Marshall Greenblatt

    If that is the case, can we accomplish the same thing using LoadURL with Data URL protocol?

    That is the recommended approach currently.

  5. Rafa Díaz

    I am facing the same issue.

    One negative side-effect of using LoadURL with Data URL protocol instead of the LoadString would be that the refresh action will not re-attempt to load the original URL, but the hard-coded error URL which is no helpful.

    Alternatives I have thought about are:

    1. Have the error page include a reload link that points to the failing URL (this is currently our behavior, so we are good on this)
    2. Have the data protocol keep a state to know if this is a reload of the error page (and then, try to reload the original page in this case), or if this is the first load of the error page (and move on with the loading of the error page)

    What do you think?

  6. Marshall Greenblatt

    @rcxrgugl Chromium has the concept of an “interstitial page” which behaves similarly to what you’re describing in 2. It is not something that we have implemented in CEF up to this point. If you are interested in implementing this functionality you can find an example in LoginInterstitialDelegate.

  7. Marshall Greenblatt

    Given that all calls to LoadString now fail with “bad IPC message” reason RFH_NO_MATCHING_NAVIGATION_REQUEST_ON_COMMIT (216) I think we should delete the LoadString method.

    Note that the LoadRequest method now only works if you first navigate to the request URL using some other mechanism (LoadURL, link click, etc). Otherwise, it will fail with “bad IPC message” reason INVALID_INITIATOR_ORIGIN (213).

  8. Mike Wiedenbauer

    Even if it’s probably the only working case, but if you’re in OnBeforeBrowse (hence within a navigation request), CefFrame::LoadString still works as expected.

    So perhaps it’d make sense to keep LoadString anyways?

  9. Marshall Greenblatt

    @Mike Wiedenbauer Is that something you’re using currently? If so, can you explain the use case in greater detail?

  10. Marshall Greenblatt

    cefclient: Move StringResourceMap to ClientHandler (see issue #2586)

    Fixes a DCHECK when creating multiple windows in cefclient due to the creation of multiple StringResourceProvider objects.

    → <<cset aad4bf246403>>

  11. Marshall Greenblatt

    cefclient: Move StringResourceMap to ClientHandler (see issue #2586)

    Fixes a DCHECK when creating multiple windows in cefclient due to the creation of multiple StringResourceProvider objects.

    → <<cset dd6c64527246>>

  12. Mike Wiedenbauer

    @Marshall Greenblatt I used it inside OnBrowseBefore to serve our own about: page(s), by examining the request URL The initial request, to trigger OnBeforeBrowse was done thru LoadURL ofcourse. But this can be solved in a different way aswell, and hence using loadURL to serve our own about page(s), for this case. I just wanted to let you know that LoadString is not completely unsupported.

  13. Joshua Chen

    I think the LoadString() should be kept and note that cefsimple is still using it for error display

    void SimpleHandler::OnLoadError(CefRefPtr<CefBrowser> browser,
                                    CefRefPtr<CefFrame> frame,
                                    ErrorCode errorCode,
                                    const CefString& errorText,
                                    const CefString& failedUrl) {
      CEF_REQUIRE_UI_THREAD();
    
      // Don't display an error for downloaded files.
      if (errorCode == ERR_ABORTED)
        return;
    
      // Display a load error message.
      std::stringstream ss;
      ss << "<html><body bgcolor=\"white\">"
            "<h2>Failed to load URL "
         << std::string(failedUrl) << " with error " << std::string(errorText)
         << " (" << errorCode << ").</h2></body></html>";
      frame->LoadString(ss.str(), failedUrl);
    }
    

  14. bobo brasil

    Hello guys. We have been using LoadString so far to display our own HTML code directly as a website in a CEF frame. Now we need to update to the new CEF version for a special fix and this function is gone. Is there any alternative? I have found only one online: frame->LoadURL(string("data:text/html;base64,") + encodeBase64(string(pResourceData), false));

    But the loaclStorage doesn’t work anymore! a URL including “data:” and LocalStorage don’t work together.

    So how can we load a site as such an object and have LoaclStorage available???

    Thank you very much in advance!

  15. Arno de Vries

    I have recently discovered this function was removed. We were using this function extensively, and the alternatives are (as far as I can see) not usable for us. Our use case is as follows:

    -We have a web server handling rest calls.

    -We have a HTML page designer which dynamically creates HTML in memory.

    -The created HTML does rest calls to the web server.

    -We use the LoadString function with the created HTML, and an URL pointing to the web server so the page “knows” where to send the rest calls.

    We therefore would appreciate it if the LoadString function was revived.

    Thank You.

  16. Yong Li

    The missing feature of LoadString is the ability of setting an arbitrary URL for the page. The solution of loading a data URL will display a super long URL in the URL bar. Is there a full alternative?

  17. petko

    What is the proposed way to set an URL for a page loaded by data uri? Removing LoadString breaks CEF for us to..

  18. Log in to comment