UpdateEventHandlerInternal() should track change in number, not existence.
In EventHandlerRegistry::UpdateEventHandlerInternal(), the function at
present only updates NotifyHasHandlersChanged() if a particular handler
class starts/stops being present. This totally ignores information
about the handler's target, which might be in a different LocalRoot,
and hence a different compositor, than any existing handlers.
In the associated bug, this means that after a handler is installed on
the first OOPIF's compositor, another won't be installed for the second
OOPIF, even though it uses a different compositor.
This CL forces the call NotifyHasHandlersChanged() any time the
*number* of handlers changes. This might seem overkill, but since we
don't have an easy way to track if the new target is in a compositor
that already has a handler, this is probably ok. (An alternative would
be to set up per-LocalRoot tracking of handlers instead.)
Bug: 820232
Change-Id: Iab5606d10b3d84375e408e0119b5ba04b3572ed6
Reviewed-on: https://chromium-review.googlesource.com/981310
Reviewed-by: Ken Buchanan <[email protected]>
Reviewed-by: Nasko Oskov <[email protected]>
Reviewed-by: David Bokan <[email protected]>
Commit-Queue: James MacLean <[email protected]>
Cr-Commit-Position: refs/heads/master@{#546866}diff --git a/content/renderer/render_widget.h b/content/renderer/render_widget.h
index b97c5fb..94d077a 100644
--- a/content/renderer/render_widget.h
+++ b/content/renderer/render_widget.h
@@ -989,6 +989,11 @@
gfx::Rect viewport_intersection_;
gfx::Rect compositor_visible_rect_;
+ // Cache whether or not we have touch handlers, to reduce IPCs sent.
+ // Different consumers in the browser process makes different assumptions, so
+ // must always send the first IPC regardless of value.
+ base::Optional<bool> has_touch_handlers_;
+
base::WeakPtrFactory<RenderWidget> weak_ptr_factory_;
DISALLOW_COPY_AND_ASSIGN(RenderWidget);
