VR Shell: Allow UI elements to determine hit testing.

chrome/browser/android/vr_shell/ui_elements/close_button.h

Index: chrome/browser/android/vr_shell/ui_elements/close_button.h
diff --git a/chrome/browser/android/vr_shell/ui_elements/close_button.h b/chrome/browser/android/vr_shell/ui_elements/close_button.h
index 682364d8d89bfcf7025bc38578fe325435f02c99..45ed4a01189a80bf7f52fd74fccd59b94489090a 100644
--- a/chrome/browser/android/vr_shell/ui_elements/close_button.h
+++ b/chrome/browser/android/vr_shell/ui_elements/close_button.h
@@ -23,16 +23,17 @@ class CloseButton : public TexturedElement {
 
   void OnHoverLeave() override;
   void OnHoverEnter(gfx::PointF position) override;
+  void OnMove(gfx::PointF position) override;
   void OnButtonDown(gfx::PointF position) override;
   void OnButtonUp(gfx::PointF position) override;
+  bool HitTest(gfx::PointF point) const override;

[cjgrant, 2017/05/15 16:55:09]

How are we going to handle elements that have two hover/clickable regions
internally?  Hopefully we won't have any for BBB, but if we did, maybe some of
the input code that was just refactored in vr_shell_gl.cc should live in a
helper class, that can be used recursively by vr_shell_gl.cc and individual
elements if needed.

That way, two hoverable/clickable buttons on (say the URL bar) would be
guaranteed to work the same as two hoverable/clickable UiElements.

Thoughts (other than "not in this CL!")?

[mthiesse, 2017/05/15 21:11:27]

Don't like it, and also "not in this CL". An element should handle it's own
internals, though if something happens to be re-usable then of course we should
reuse it. The main reason not to share code is in-element hit-testing is 2D, and
scene hit-testing is 3D.

 
  private:
   UiTexture* GetTexture() const override;
-  void OnStateUpdated();
+  void OnStateUpdated(gfx::PointF position);
 
   std::unique_ptr<CloseButtonTexture> texture_;
   bool down_ = false;
-  bool hover_ = false;
   base::Callback<void()> click_handler_;
 
   DISALLOW_COPY_AND_ASSIGN(CloseButton);