Commit ddc6aa83 authored by Mario Bianucci's avatar Mario Bianucci Committed by Commit Bot

Add is_bound check to receiver_ in DelegatedInkPointRendererBase

Because RenderWidgets exist 1:1 with tabs, if delegated ink trails are
being used in one tab, and then another tab starts using them, a second
mojo pipeline between browser proc and viz will try to be created.
However, since there is only one receiver in viz and it is already
bound, we hit a DCHECK() and crash.

The fix is to just add an if check in viz, and if the receiver is already
bound, then reset it and bind the new PendingReceiver. This makes sure
that the feature is available on the most recent tab to use it.

Moving the Remote from RenderWidgetHostViewEventHandler to somewhere
that it can exist 1:many with tabs is another possible solution. This
would also have the benefit of exactly one IPC to make the connection
for all tabs in a window. However, that would require the Remote to move
to a much less obvious place for it to live, and since the trade off is
only one extra IPC call per tab switch (when the new tab starts using
the API - if it never uses it, no IPC call), it is unlikely to cause any
noticeable performance regression.

Bug: 1138602
Change-Id: I2ea9bb0962ac6e67b21276d0b75d9c455e7ede76
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2472901Reviewed-by: default avatarJonathan Ross <jonross@chromium.org>
Reviewed-by: default avatarDaniel Libby <dlibby@microsoft.com>
Commit-Queue: Mario Bianucci <mabian@microsoft.com>
Cr-Commit-Position: refs/heads/master@{#817672}
parent 0ef73f4e
...@@ -14,6 +14,16 @@ DelegatedInkPointRendererBase::~DelegatedInkPointRendererBase() = default; ...@@ -14,6 +14,16 @@ DelegatedInkPointRendererBase::~DelegatedInkPointRendererBase() = default;
void DelegatedInkPointRendererBase::InitMessagePipeline( void DelegatedInkPointRendererBase::InitMessagePipeline(
mojo::PendingReceiver<mojom::DelegatedInkPointRenderer> receiver) { mojo::PendingReceiver<mojom::DelegatedInkPointRenderer> receiver) {
// The remote end of this pipeline exists on a per-tab basis, so if tab A
// is using the feature and then tab B starts trying to use it, a new
// PendingReceiver will arrive here while |receiver_| is still bound to the
// remote in tab A. In this case, just reset |receiver_| so that tab A's
// remote is unbound and bind the new receiver to use the feature in tab B.
if (receiver_.is_bound()) {
receiver_.reset();
metadata_.reset();
points_.clear();
}
receiver_.Bind(std::move(receiver)); receiver_.Bind(std::move(receiver));
} }
......
Markdown is supported
0%
or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment