VR: Content does not lose hover when reticle moves to another element |
||||||||
Issue descriptionFound in ToT today. When a web input field has focus, the keyboard is up. However, links on the page still react to hover. Having the keyboard present makes it easy to see that when the reticle moves over the keyboard, content doesn't seem to get notified that it doesn't have the cursor anymore. I can reproduce this using the Wikipedia search field - see attached. The "Desktop" link maintains its hover state, despite the reticle hovering on keyboard.
,
Mar 7 2018
This is not really a keyboard specific issue. Looks like we're not sending input events correctly when the element being hit changes. For example, you notice the same thing when you move the reticle outside of the content quad quickly: https://jsbin.com/jerokac
,
Mar 7 2018
Yes, totally agree on that. The keyboard just makes it easy to see the problem. It seems like, after the reticle moves off content, we should be sending some kind of follow-up when content loses the hover, so that content doesn't keep thinking the reticle is floating in the last spot it existed.
,
Apr 6 2018
,
Apr 9 2018
I filed a duplicate of this a month later, forgetting this original one still existed. Linking them now.
,
Apr 9 2018
,
Apr 17 2018
,
Apr 17 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/de98f7a44acc6d1664617d8666b53d36c4215331 commit de98f7a44acc6d1664617d8666b53d36c4215331 Author: Yash Malik <ymalik@google.com> Date: Tue Apr 17 17:26:20 2018 VR: Fix injected hover events for web contents Injecting HOVER_EXIT is done by the platform if the coordinates for the HOVER_MOVE are out of bounds, so we don't need to inject it ourself. Bug: 819348 Change-Id: I4486f9970fac031373215bdcb7021de6a422da02 Reviewed-on: https://chromium-review.googlesource.com/1014715 Reviewed-by: Michael Thiessen <mthiesse@chromium.org> Commit-Queue: Yash Malik <ymalik@chromium.org> Cr-Commit-Position: refs/heads/master@{#551375} [modify] https://crrev.com/de98f7a44acc6d1664617d8666b53d36c4215331/chrome/browser/android/vr/android_ui_gesture_target.cc
,
Apr 18 2018
,
Apr 19 2018
Your change meets the bar and is auto-approved for M67. Please go ahead and merge the CL to branch 3396 manually. Please contact milestone owner if you have questions. Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Apr 19 2018
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3a4dc784c83385e4784aba9314f971d0d90b7d26 commit 3a4dc784c83385e4784aba9314f971d0d90b7d26 Author: Yash Malik <ymalik@google.com> Date: Thu Apr 19 20:01:30 2018 VR: Fix injected hover events for web contents Injecting HOVER_EXIT is done by the platform if the coordinates for the HOVER_MOVE are out of bounds, so we don't need to inject it ourself. Bug: 819348 Change-Id: I4486f9970fac031373215bdcb7021de6a422da02 Reviewed-on: https://chromium-review.googlesource.com/1014715 Reviewed-by: Michael Thiessen <mthiesse@chromium.org> Commit-Queue: Yash Malik <ymalik@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#551375}(cherry picked from commit de98f7a44acc6d1664617d8666b53d36c4215331) Reviewed-on: https://chromium-review.googlesource.com/1019966 Reviewed-by: Yash Malik <ymalik@chromium.org> Cr-Commit-Position: refs/branch-heads/3396@{#145} Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428} [modify] https://crrev.com/3a4dc784c83385e4784aba9314f971d0d90b7d26/chrome/browser/android/vr/android_ui_gesture_target.cc
,
Apr 19 2018
,
May 8 2018
|
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by cjgrant@chromium.org
, Mar 6 2018393 KB
393 KB View Download