Here's the patch that shows the issue:
- Code: Select all
--- tests/cefclient/renderer/client_renderer.cc (revision e9215231011245a6ea058bca942ee9355c6cbbac)
+++ tests/cefclient/renderer/client_renderer.cc (date 1593798228317)
@@ -24,8 +24,10 @@
public:
ClientRenderDelegate() : last_node_is_editable_(false) {}
+ int counter = 0;
void OnRenderThreadCreated(CefRefPtr<ClientAppRenderer> app,
CefRefPtr<CefListValue> extra_info) OVERRIDE {
+ counter = extra_info->GetInt(0);
if (CefCrashReportingEnabled()) {
// Set some crash keys for testing purposes. Keys must be defined in the
// "crash_reporter.cfg" file. See cef_crash_util.h for details.
@@ -48,6 +50,7 @@
CefRefPtr<CefBrowser> browser,
CefRefPtr<CefFrame> frame,
CefRefPtr<CefV8Context> context) OVERRIDE {
+ browser->GetMainFrame()->ExecuteJavaScript("alert('" + std::to_string(counter) + "');", "", 0);
message_router_->OnContextCreated(browser, frame, context);
}
===================================================================
--- tests/shared/browser/client_app_browser.cc (revision e9215231011245a6ea058bca942ee9355c6cbbac)
+++ tests/shared/browser/client_app_browser.cc (date 1593798228325)
@@ -81,11 +81,14 @@
(*it)->OnBeforeChildProcessLaunch(this, command_line);
}
+static int counter = 0;
void ClientAppBrowser::OnRenderProcessThreadCreated(
CefRefPtr<CefListValue> extra_info) {
DelegateSet::iterator it = delegates_.begin();
for (; it != delegates_.end(); ++it)
(*it)->OnRenderProcessThreadCreated(this, extra_info);
+
+ extra_info->SetInt(0, counter++);
}
void ClientAppBrowser::OnScheduleMessagePumpWork(int64 delay) {
Here we're just passing sequential indices starting from 0 to each new render process using extra_info. Render process then calls 'alert' in JS printing its index. We expect to see values 0, 1, 2, 3, ... with each new browser window (which is the case with older CEF versions, specifically 77.1.18+g8e8d602+chromium-77.0.3865.120), but in current versions, when opening new browser windows we see a different sequence: 1, 0, 2, 3, 4, ...
As ClientAppBrowser::OnRenderProcessThreadCreated is called twice on startup, it puts 0 and 1 in extra_info on first 2 runs and first browser window gets 1, seems like 0 is 'queued'. When opening second browser window, we're putting 2 into extra_info, but new browser window receives 0. Now, 2 is queued and will be passed to next browser window.
That's it, extra_info data recorded in ClientAppBrowser::OnRenderProcessThreadCreated for specific render process, in fact is passed to next render process. It completely breaks synchronization between browser and render processes when opening new windows. Again, that behavior is certainly wrong, as there's no such synchronization problems in 77.1.18+g8e8d602+chromium-77.0.3865.120 and ClientAppBrowser::OnRenderProcessThreadCreated is called only once there.
Version on which issue was reproduced: 83.4.2+gc8d4f85+chromium-83.0.4103.106
Ubuntu 18.04 x64
This issue is a root of another issue: viewtopic.php?f=17&t=17599 and was found when researching the latter. It also states that this issue appeared with 78.2.7+g9cd8bac+chromium-78.0.3904.70