Auto-hidden Disconnect Window is reshown w/o local input |
|||||||
Issue descriptionA recent update to the Me2Me disconnect window for Windows was to allow it to auto-hide after several seconds of inactivity on the local machine. After shipping the change we started receiving reports of the window being reshown when there is no local input. I suspect this could be due to a HID device sending spurious input events. More investigation will be needed to know for sure.
,
Oct 3
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/edc50bc7d6901596d8579db67470edd17e827e9c commit edc50bc7d6901596d8579db67470edd17e827e9c Author: Joe Downing <joedow@chromium.org> Date: Wed Oct 03 19:02:53 2018 Do not reshow the disconnect window for small mouse movements This change adds a fudge factor of ~1px to the logic which determines whether to reshow the disconnect window after it has been hidden. I suspect the reports of the window being reshown are due to small accumulations for the cursor position or potentially just raw input events where the cursor does not change. We want to avoid reshowing the dialog in cases such as this because it is quite annoying for the remote user. Bug: 891584 Ignore mouse messages if the position or button states don't change We've received reports that the disconnect window is appearing at odd times after the auto-hide timeout has taken effect. I suspect there could be hardware which is emitting spurious HID events which is triggering the reshow logic. My assumption is that this behavior is't egregious, otherwise the user would notice the mouse cursor moving or errant keypresses. Thus I want to prevent triggering the reshow logic if we receive a RAWINPUT event where the cursor has not moved and no button states have changed. Change-Id: I310f2cb4a5f30b0b7e14bf7221d250030492add8 Reviewed-on: https://chromium-review.googlesource.com/c/1258979 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Jamie Walch <jamiewalch@chromium.org> Cr-Commit-Position: refs/heads/master@{#596308} [modify] https://crrev.com/edc50bc7d6901596d8579db67470edd17e827e9c/remoting/host/disconnect_window_win.cc
,
Oct 3
I'd like to request a merge for these two CLs into M70 if we aren't past the point where merges are allowed. This change only affects the Chrome Remote Desktop host. It addresses a problem we found during our 10% push. Merging now would allow us to release this a couple of weeks earlier than waiting for M71.
,
Oct 3
This bug requires manual review: We are only 12 days from stable. Please contact the milestone owner if you have questions. Owners: benmason@(Android), kariahda@(iOS), geohsu@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 3
Is this independent of the chrome release cycle?
,
Oct 3
Our team chooses release candidate builds from the release branch (to ensure the lower level components (base/net/etc) we rely on are stable. We aren't tied to the specific Dev/Beta/Stable channel release process for Windows/Mac/Linux. ChromeOS follows this process but the change I would like to merge only affects our Windows host.
,
Oct 4
,
Oct 4
Thanks!
,
Oct 4
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4b399f91a3ac7c75daf69674466e17853a2b19e8 commit 4b399f91a3ac7c75daf69674466e17853a2b19e8 Author: Joe Downing <joedow@chromium.org> Date: Thu Oct 04 18:33:24 2018 Ignore mouse messages if the position or button states don't change We've received reports that the disconnect window is appearing at odd times after the auto-hide timeout has taken effect. I suspect there could be hardware which is emitting spurious HID events which is triggering the reshow logic. My assumption is that this behavior is't egregious, otherwise the user would notice the mouse cursor moving or errant keypresses. Thus I want to prevent triggering the reshow logic if we receive a RAWINPUT event where the cursor has not moved and no button states have changed. Bug: 891584 Change-Id: Id9efd72f24f8caf0e67b1a717fee2bbafaab55af Reviewed-on: https://chromium-review.googlesource.com/c/1258316 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Jamie Walch <jamiewalch@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#596121}(cherry picked from commit df242b026028cda8d2c3564f0e5129059d7bb7bd) Reviewed-on: https://chromium-review.googlesource.com/c/1262419 Reviewed-by: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#857} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811} [modify] https://crrev.com/4b399f91a3ac7c75daf69674466e17853a2b19e8/remoting/host/input_monitor/local_mouse_input_monitor_win.cc
,
Oct 4
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3c49fc56ac9a9d5e2db1d615b6cac8c27382539e commit 3c49fc56ac9a9d5e2db1d615b6cac8c27382539e Author: Joe Downing <joedow@chromium.org> Date: Thu Oct 04 18:34:15 2018 Do not reshow the disconnect window for small mouse movements This change adds a fudge factor of ~1px to the logic which determines whether to reshow the disconnect window after it has been hidden. I suspect the reports of the window being reshown are due to small accumulations for the cursor position or potentially just raw input events where the cursor does not change. We want to avoid reshowing the dialog in cases such as this because it is quite annoying for the remote user. Bug: 891584 Ignore mouse messages if the position or button states don't change We've received reports that the disconnect window is appearing at odd times after the auto-hide timeout has taken effect. I suspect there could be hardware which is emitting spurious HID events which is triggering the reshow logic. My assumption is that this behavior is't egregious, otherwise the user would notice the mouse cursor moving or errant keypresses. Thus I want to prevent triggering the reshow logic if we receive a RAWINPUT event where the cursor has not moved and no button states have changed. Change-Id: I310f2cb4a5f30b0b7e14bf7221d250030492add8 Reviewed-on: https://chromium-review.googlesource.com/c/1258979 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Jamie Walch <jamiewalch@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#596308}(cherry picked from commit edc50bc7d6901596d8579db67470edd17e827e9c) Reviewed-on: https://chromium-review.googlesource.com/c/1262420 Reviewed-by: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#858} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811} [modify] https://crrev.com/3c49fc56ac9a9d5e2db1d615b6cac8c27382539e/remoting/host/disconnect_window_win.cc
,
Oct 4
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/3c49fc56ac9a9d5e2db1d615b6cac8c27382539e Commit: 3c49fc56ac9a9d5e2db1d615b6cac8c27382539e Author: joedow@chromium.org Commiter: joedow@chromium.org Date: 2018-10-04 18:34:15 +0000 UTC Do not reshow the disconnect window for small mouse movements This change adds a fudge factor of ~1px to the logic which determines whether to reshow the disconnect window after it has been hidden. I suspect the reports of the window being reshown are due to small accumulations for the cursor position or potentially just raw input events where the cursor does not change. We want to avoid reshowing the dialog in cases such as this because it is quite annoying for the remote user. Bug: 891584 Ignore mouse messages if the position or button states don't change We've received reports that the disconnect window is appearing at odd times after the auto-hide timeout has taken effect. I suspect there could be hardware which is emitting spurious HID events which is triggering the reshow logic. My assumption is that this behavior is't egregious, otherwise the user would notice the mouse cursor moving or errant keypresses. Thus I want to prevent triggering the reshow logic if we receive a RAWINPUT event where the cursor has not moved and no button states have changed. Change-Id: I310f2cb4a5f30b0b7e14bf7221d250030492add8 Reviewed-on: https://chromium-review.googlesource.com/c/1258979 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Jamie Walch <jamiewalch@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#596308}(cherry picked from commit edc50bc7d6901596d8579db67470edd17e827e9c) Reviewed-on: https://chromium-review.googlesource.com/c/1262420 Reviewed-by: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#858} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
,
Oct 4
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/4b399f91a3ac7c75daf69674466e17853a2b19e8 Commit: 4b399f91a3ac7c75daf69674466e17853a2b19e8 Author: joedow@chromium.org Commiter: joedow@chromium.org Date: 2018-10-04 18:33:24 +0000 UTC Ignore mouse messages if the position or button states don't change We've received reports that the disconnect window is appearing at odd times after the auto-hide timeout has taken effect. I suspect there could be hardware which is emitting spurious HID events which is triggering the reshow logic. My assumption is that this behavior is't egregious, otherwise the user would notice the mouse cursor moving or errant keypresses. Thus I want to prevent triggering the reshow logic if we receive a RAWINPUT event where the cursor has not moved and no button states have changed. Bug: 891584 Change-Id: Id9efd72f24f8caf0e67b1a717fee2bbafaab55af Reviewed-on: https://chromium-review.googlesource.com/c/1258316 Commit-Queue: Joe Downing <joedow@chromium.org> Reviewed-by: Jamie Walch <jamiewalch@chromium.org> Cr-Original-Commit-Position: refs/heads/master@{#596121}(cherry picked from commit df242b026028cda8d2c3564f0e5129059d7bb7bd) Reviewed-on: https://chromium-review.googlesource.com/c/1262419 Reviewed-by: Joe Downing <joedow@chromium.org> Cr-Commit-Position: refs/branch-heads/3538@{#857} Cr-Branched-From: 79f7c91a2b2a2932cd447fa6f865cb6662fa8fa6-refs/heads/master@{#587811}
,
Oct 4
|
|||||||
►
Sign in to add a comment |
|||||||
Comment 1 by bugdroid1@chromium.org
, Oct 3