[md] Give each infobar its own layer.

chrome/browser/ui/views/infobars/infobar_view.cc

Index: chrome/browser/ui/views/infobars/infobar_view.cc
diff --git a/chrome/browser/ui/views/infobars/infobar_view.cc b/chrome/browser/ui/views/infobars/infobar_view.cc
index f5cde5e814d8aeff283ce5a193c4ab85858f0d0e..97b944a811100e186d0fdd59b8c689d23d3442c7 100644
--- a/chrome/browser/ui/views/infobars/infobar_view.cc
+++ b/chrome/browser/ui/views/infobars/infobar_view.cc
@@ -84,10 +84,14 @@ InfoBarView::InfoBarView(scoped_ptr<infobars::InfoBarDelegate> delegate)
   set_owned_by_client();  // InfoBar deletes itself at the appropriate time.
   set_background(
       new InfoBarBackground(infobars::InfoBar::delegate()->GetInfoBarType()));
+  SetEventTargeter(make_scoped_ptr(new views::ViewTargeter(this)));
 
   AddChildView(child_container_);
 
   if (ui::MaterialDesignController::IsModeMaterial()) {
+    SetPaintToLayer(true);
+    layer()->SetFillsBoundsOpaquely(false);
+
     child_container_->SetPaintToLayer(true);
     child_container_->layer()->SetMasksToBounds(true);
     // Since MD doesn't use a gradient, we can set a solid bg color.
@@ -429,3 +433,9 @@ void InfoBarView::OnWillChangeFocus(View* focused_before, View* focused_now) {
     NotifyAccessibilityEvent(ui::AX_EVENT_ALERT, true);
   }
 }
+
+bool InfoBarView::DoesIntersectRect(const View* target,
+                                    const gfx::Rect& rect) const {
+  DCHECK_EQ(this, target);
+  return rect.CenterPoint().y() >= arrow_height();

[Peter Kasting, 2016/03/08 01:08:17]

This doesn't seem right... if the goal is to allow any rect that overlaps the
below-arrow portion, this doesn't do that, and if the goal is to block any rect
that overlaps the arrow portion, this doesn't do that either.

Much like with the container view, this inequality makes me extremely
uncomfortable, and I'd much rather have a true rect intersection check with the
relevant portion of our bounds.

[Evan Stade, 2016/03/08 01:43:29]

ditto to my other comment. The two behaviors described above are not goals. The
goal is to accept any rectangle that is more inside than out and reject any
rectangle that is more outside than in.

[Peter Kasting, 2016/03/08 03:11:04]

After reading your other comments, it seems like you're implying that if |rect|
is bigger than a point, that it represents the bounds of some kind of touch
event?  Is that documented somewhere?  (Because it sure isn't on ViewTargeter.) 
Is checking the center point of such a rect the canonical right way to handle
such a case?  It seems like there needs to be more comments here and possibly on
ViewTargeter and possible also elsewhere (I dunno) about all this as I have very
little idea of what's going on or why you would want to "accept any rectangle
that is more inside than out and reject any rectangle that is more outside than
in".

[tdanderson, 2016/03/14 17:53:03]

This should also use rect.bottom() instead of rect.CenterPoint().y(). |rect|
does indeed represent the bounding box of a touch region. The  purpose of
DoesIntersectRect() is just to return the result of a hit test of |rect| against
|this|. For the case of an infobar, you want to allow events in the rectangular
portion of the bar, but not allow events in the arrow part. So the hit test
should succeed if the rect intersects with any non-arrow part of the infobar.

Now let's say the infobar arrow appears over top of a bookmark button, and you
try to tap this button. Even if some of your finger overlaps the rectangular
part of the bookmark bar (meaning DoesIntersectRect() returns true for the
infobar), that's fine; it's the job of ViewTargeterDelegate::TargetForRect() to
find the most probable target of the tap among all of the potential targets
(i.e., the targets underneath your finger).

The documentation for this is in the header of ViewTargeterDelegate. But after
reading this over with fresh eyes I think clarity could be improved by re-naming
DoesIntersectRect() to something like IsCandidateForEventTargeting(),
DoesIntersectHitTestRegion(), etc. WDYT?

+}