Inconsistent behavior with setURL and initialization on different threads

[ScottPeterJohnson]

Describe the bug
After creating the CEF browser, attempts to call setUrl() may silently fail if done before the browser has actually been loaded.

My code is a bit tangled so it'd take me work to make a minimal repro, but you can see the issue from the code itself here:

java-cef/native/CefBrowser_N.cpp

Line 1185 in 68943f2

Java_org_cef_browser_CefBrowser_1N_N_1CreateBrowser(JNIEnv* env,

if (CefCurrentlyOn(TID_UI)) {
    create(objs, windowHandle, osr, transparent);
  } else {
    CefPostTask(TID_UI,
                base::BindOnce(&create, objs, windowHandle, osr, transparent));
  }

If not created from the TID_UI thread (whatever that is), the actual create() call will be done asynchronously. But loadURL (and really most anything on the browser interface) works like this:

JNIEXPORT void JNICALL
Java_org_cef_browser_CefBrowser_1N_N_1LoadURL(JNIEnv* env,
                                              jobject obj,
                                              jstring url) {
  CefRefPtr<CefBrowser> browser = JNI_GET_BROWSER_OR_RETURN(env, obj);
  browser->GetMainFrame()->LoadURL(GetJNIString(env, url));
}

Meaning it will silently fail if called too soon after calling createBrowser().

(See here for another person running into problems with the behavior of CEfBrowser_N.createBrowser(): #421 (comment) )

Expected behavior
Most likely, createBrowser() should block until a browser is created. Or it should be clearer that nothing on the CefBrowser interface will work until then.

[magreenblatt]

As you discovered, you should pas the URL when creating the browser, or wait until onAfterCreated is called.

it should be clearer that nothing on the CefBrowser interface will work until then.

Fair point.