Issue metadata
Sign in to add a comment
|
Regression: Guest window goes behind Normal window after tap touch on Restore button
Reported by
khushal....@etouch.net,
Jul 23
|
||||||||||||||||||||||
Issue descriptionChrome Version: 70.0.3500.0 (Official Build) Revision 19fb8c745affb4c0f621296e66bac6094e692076-refs/branch-heads/3500@{#1} (32/64 bit) OS: Windows 10 (Touch device) What steps will reproduce the problem? (1) Launch chrome and Tap Touch on "Open Guest Window" from Avatar menu. (2) Now tap touch on "Restore" button of Guest Window and Observe. Actual Result: Guest window goes behind Normal window after tap touch on Restore button. Expected Result: Guest window should restore over Normal window after tap touch on Restore button. This is a regression issue, broken in 'M-69' series and providing the bisect info below: Good Build: 69.0.3451.0 (Revision: 564769) Bad Build: 69.0.3452.0 (Revision: 565143) Narrow Bisect URL: https://chromium.googlesource.com/chromium/src/+log/a65096e65014ee0ea87c8ef7b256b45d049a59a0..90ed0473c4772dd6e0df9242dd0863cb81e85cd3?pretty=fuller&n=10000 Suspect: r565126 ? @pbos: Could you please check whether this is caused with respect to your change, if not please help us in assigning it to the right owner. Note: 1) Issue is Touch specific and it is not seen on Click event. 2) Issue is also seen on M-69 Dev (build #69.0.3493.3). 3) Issue is not seen on Linux (14.04 LTS) and Mac (10.12.6, 10.13.1, 10.13.6, 10.14) OS. Kindly refer the attached screen-cast. Thank You..!!
,
Jul 23
Hmm, that was bug 832291 but I fixed it already. This is probably a separate issue. All the more reason to get someone to work on touch...
,
Jul 23
,
Jul 23
,
Oct 10
--Chrome Identity automated triaging-- This bug is P0 or P1 and has gone two weeks without any activity. Please provide a status update or lower the priority. Please see https://goo.gl/78kbny for more details. Please remove the Services>SignIn or UI>Browser>Profiles components if this bug isn't related to Chrome Identity. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Oct 10
Removing the Profiles component, since this is really a touch issue.
,
Oct 12
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/c6058c3e1f9a4118c88bf487e6c5a3fe2f562269 commit c6058c3e1f9a4118c88bf487e6c5a3fe2f562269 Author: Bret Sepulveda <bsep@chromium.org> Date: Fri Oct 12 00:36:13 2018 Mark touch released events handled by default on Windows. When a touch event is not handled, WindowEventDispatcher will generate gesture events from it. However, when those gesture events are marked as handled that handling doesn't propagate back to the original touch event. For bug 852241 , the hamburger menu only handles gesture events. On Windows, selecting an option with a touch would cause the hamburger menu to close, but because the touch event wasn't marked as handled Windows would pass it along to the underlying window, causing it to gain focus. Most of the time it would be gaining focus anyway (since the hamburger menu just closed) so this isn't noticeable, but the Cast dialog is a newly-added surface that closes if it loses focus. In this case, it seems to not appear at all. Similarly for bug 866421 , when the guest window becomes restored it reveals the window underneath and then Windows passes the event along, giving it focus. This patch marks all touch released as handled by default, which prevents Windows from ever propagating them. These events generate the tap gestures that cause the state change in the hamburger menu and window size in the above bugs. Bug: 852241 , 866421 Change-Id: I10a67d56fdc46d5b91282e0f395c895339f71951 Reviewed-on: https://chromium-review.googlesource.com/c/1260507 Commit-Queue: Bret Sepulveda <bsep@chromium.org> Reviewed-by: Scott Violet <sky@chromium.org> Cr-Commit-Position: refs/heads/master@{#599037} [modify] https://crrev.com/c6058c3e1f9a4118c88bf487e6c5a3fe2f562269/ui/views/win/hwnd_message_handler.cc
,
Oct 12
|
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by pbos@chromium.org
, Jul 23Owner: bsep@chromium.org