Instant Extended: Suppress mouse events for bottom web content

content/browser/renderer_host/render_widget_host_view_mac.mm

 // Copyright (c) 2012 The Chromium Authors. All rights reserved.
 // Use of this source code is governed by a BSD-style license that can be
 // found in the LICENSE file.
 
 #include "content/browser/renderer_host/render_widget_host_view_mac.h"
 
 #include <QuartzCore/QuartzCore.h>
 
 #include "base/bind.h"
 #include "base/bind_helpers.h"
@@ skipping 1711 matching lines @@
   // Use hitTest to check whether the mouse is over a nonWebContentView - in
   // which case the mouse event should not be handled by the render host.
   const SEL nonWebContentViewSelector = @selector(nonWebContentView);
   NSView* contentView = [window contentView];
   NSView* view = [contentView hitTest:[theEvent locationInWindow]];
   // Traverse the superview hierarchy as the hitTest will return the frontmost
   // view, such as an NSTextView, while nonWebContentView may be specified by
   // its parent view.
   while (view) {
     if ([view respondsToSelector:nonWebContentViewSelector] &&
         [view performSelector:nonWebContentViewSelector]) {

[Avi (use Gerrit), 2013/05/28 20:11:06]

What the heck?

[Alexei Svitkine (slow), 2013/05/28 20:37:59]

You can blame Mento for this, if you want. ;)

I think this was my first Chromium CL - I believe I originally just did a
-isKindOfClass: check against the find bar but we wanted a more general
solution, so the suggestion was for views to implement -nonWebContentView to
indicate they block events from going to the renderer. (vs. views that are part
of web content, like a plugin container iirc)

[Avi (use Gerrit), 2013/05/28 20:41:54]

:( I would hope for something a little more magical, like saying, "hey, if I'm
in the background then don't look at me". (shrug) Oh well, I'm not objecting to
this CL due to this...

[Alexei Svitkine (slow), 2013/05/28 20:44:29]

(It does that too using the -hitTest: above. The problem is differentiating a
plugin container view vs. a find bar view, both in the foreground w.r.t. to the
render view - but the plugin view wanting events to go to the renderer, while
the find bar not wanting this.)

[Avi (use Gerrit), 2013/05/28 20:47:52]

Oh. Eeew.

Does this change now that we have compositing everywhere? Do we still have
plugin containers?

[Alexei Svitkine (slow), 2013/05/28 20:58:12]

No clue.

       // The cursor is over a nonWebContentView - ignore this mouse event.
       return YES;
     }
+    if ([view isKindOfClass:[self class]] && ![view isEqual:self]) {
+      // The cursor is over an overlapping render widget. This check is done by
+      // both views so the one that's returned by -hitTest: will end up
+      // processing the event.
+      return YES;
+    }
     view = [view superview];
   }
   return NO;
 }
 
 - (void)mouseEvent:(NSEvent*)theEvent {
   TRACE_EVENT0("browser", "RenderWidgetHostViewCocoa::mouseEvent");
   if (delegate_ && [delegate_ respondsToSelector:@selector(handleEvent:)]) {
     BOOL handled = [delegate_ handleEvent:theEvent];
     if (handled)
@@ skipping 1654 matching lines @@
   if (!string) return NO;
 
   // If the user is currently using an IME, confirm the IME input,
   // and then insert the text from the service, the same as TextEdit and Safari.
   [self confirmComposition];
   [self insertText:string];
   return YES;
 }
 
 @end