https://chromium.googlesource.com/chromium/src/+/0c5c3f49f31a1f438d8515f9cf6967d10e49dea7commit 0c5c3f49f31a1f438d8515f9cf6967d10e49dea7
Author: Dominic Farolino <
d...@chromium.org>
Date: Wed Feb 17 17:40:15 2021
Migrate GinJavaBridgeMessageFilter to be 1:1 with AgentSchedulingGroup
Before this CL, GinJavaBridgeMessageFilter was 1:1 with
RenderProcessHost. GinJavaBridgeMessageFilter was installed on the
process-global IPC channel to handle the GinJavaBridgeHostMsg_*
messages sent from the renderer process.
In MBI mode, this caused a problem because:
- All renderer-to-browser messages bound for the
GinJavaBridgeMessageFilter are sent via the AgentSchedulingGroup IPC
channel that the sender is associated with (via RenderFrameImpl)
- Even if these messages were sent over the process-global IPC channel
and thus received correctly in the browser, the ordering between and
all navigation-associated messages would be broken, which breaks
fundamental guarantees required by the GinJavaBridgeMessage system
After this CL, GinJavaBridgeMessageFilter is 1:1 with
AgentSchedulingGroup(Host), and therefore there are as many filters
associated with a RenderProcessHost as there are
AgentSchedulingGroupHosts. Each GinJavaBridgeMessageFilter is installed
on the appropriate AgentSchedulingGroup's IPC channel, so that it can
correctly receive messages and process messages from the browser. This
fixes 372 failing Android tests in MBI mode. We're currently only
experimenting with the
kEnabledPerRenderProcessHost MBI mode [1], which creates a single
AgentSchedulingGroupHost per RenderProcessHost, and the
AgentSchedulingGroupHost has its own legacy IPC channel over which
messages that don't preserve ordering with the process-global IPC
channel go.
This CL has no effect when MBI mode is disabled, because it makes as
many GinJavaBridgeMessageFilters as there are AgentSchedulingGroupHosts,
and in MBI's kLegacy mode (disabled) there is only one
AgentSchedulingGroupHost per RenderProcessHost, and all communication
through it gets forwarded to the process-global IPC channel, (the
AgentSchedulingGroupHost does not have an IPC channel of its own in this
mode, to preserve the legacy behavior).
The renderer-side GinJavaBridgeObject can outlive the RenderFrame it is
associated with, however it still needs to send a trailing object
deletion message to the browser process on destruction. We can't send
this message over the AgentSchedulingGroup's IPC channel, since the
RenderFrameImpl we would grab the channel from may be gone. This message
must be sent over the process-global IPC channel. So this CL introduces
a new GinJavaBridgeObjectDeletionMessageFilter that only handles the
trailing object deletion message filter sent over the process-global IPC
channel. It is only ever used in MBI mode.
As a part of the Java bridge mojofication work that will be finished in
the future, we can connect these message filters to their Blink-side
mojo receiver objects, completing the mojofication of the Java bridge.
But until then, in order to get MBI mode functioning, the message
granularity changes introduced in this CL are necessary.
[1]:
https://source.chromium.org/chromium/chromium/src/+/master:content/public/common/content_features.h;l=99;drc=2ac64302ae161cd6b5e4b1254497bdf5fd6d3415NOPRESUBMIT=true
Bug: 1158656
Change-Id: I0c8e0f1d64f3602e9fe08e90725c4fb8810ec25c
Reviewed-on:
https://chromium-review.googlesource.com/c/chromium/src/+/2681232Reviewed-by: Richard Coles <
to...@chromium.org>
Reviewed-by: Nasko Oskov <
na...@chromium.org>
Reviewed-by: Kouhei Ueno <
kou...@chromium.org>
Reviewed-by: Tim Volodine <
timvo...@chromium.org>
Commit-Queue: Dominic Farolino <
d...@chromium.org>
Cr-Commit-Position: refs/heads/master@{#854833}
[modify]
https://crrev.com/0c5c3f49f31a1f438d8515f9cf6967d10e49dea7/content/browser/renderer_host/agent_scheduling_group_host.cc[modify]
https://crrev.com/0c5c3f49f31a1f438d8515f9cf6967d10e49dea7/content/browser/renderer_host/agent_scheduling_group_host.h[modify]
https://crrev.com/0c5c3f49f31a1f438d8515f9cf6967d10e49dea7/content/browser/android/java/gin_java_bridge_message_filter.cc[modify]
https://crrev.com/0c5c3f49f31a1f438d8515f9cf6967d10e49dea7/content/browser/android/java/gin_java_bridge_dispatcher_host.cc[add]
https://crrev.com/0c5c3f49f31a1f438d8515f9cf6967d10e49dea7/content/browser/android/java/gin_java_bridge_object_deletion_message_filter.h[modify]
https://crrev.com/0c5c3f49f31a1f438d8515f9cf6967d10e49dea7/content/browser/BUILD.gn[modify]
https://crrev.com/0c5c3f49f31a1f438d8515f9cf6967d10e49dea7/content/public/browser/browser_message_filter.h[add]
https://crrev.com/0c5c3f49f31a1f438d8515f9cf6967d10e49dea7/content/browser/android/java/gin_java_bridge_object_deletion_message_filter.cc[modify]
https://crrev.com/0c5c3f49f31a1f438d8515f9cf6967d10e49dea7/content/browser/android/java/gin_java_bridge_message_filter.h