New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 831070 link

Starred by 2 users

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Windows
Pri: 3
Type: Bug-Regression



Sign in to add a comment

Regression:Unable to minimize,restore down and close the browser window if wrench menu is open on Win 10 Touch device.

Reported by vku...@etouch.net, Apr 10 2018

Issue description

Chrome Version: 67.0.3393.0 (Official Build) Revision	3298a607d7e8b39d8426591a1edc48b8cf7eaa7a-refs/heads/master@{#549377} (64-bit) 
OS: Windows 10 Touch device
 
What steps will reproduce the problem?
(1)Launch chrome and tap on wrench menu > new incognito window
(2)Again tap on wrench menu and try to tap/touch on minimize, restore down and close button,Observe

Actual: Unable to minimize,restore down and close the browser window if wrench menu is open.

Expected: Should be able to minimize,restore down and close the browser window even if wrench menu is open.

This is a regression issue broken in 'M67' and below is the manual bisect info
Good Build: 67.0.3377.0(Revision:544611)
Bad Build:  67.0.3378.0(Revision:544931)

Note: Issue not seen on Windows(7,8,8.1,10),Mac(10.12.6,10.13.1,10.13.5) and Linux(14.04 LTS) OS

 
Actual_Result.mp4
162 KB View Download
Expected_Result.mp4
178 KB View Download

Comment 1 by grt@chromium.org, Apr 10 2018

Cc: eirage@chromium.org
could this be related to r544619?

Comment 2 by vku...@etouch.net, Apr 10 2018

Labels: hasbisect-per-revision RegressedIn-67 Target-67 FoundIn-67
Owner: bsep@chromium.org
Status: Assigned (was: Unconfirmed)
You are probably looking for a change made after 544787 (known good), but no later than 544788 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.
https://chromium.googlesource.com/chromium/src/+log/cd54fed5e109370d5dd84d59e01819c1b786aefd..979c3c4d8355e456339c648db65c8201991b43af

Suspecting: https://chromium.googlesource.com/chromium/src/+/979c3c4d8355e456339c648db65c8201991b43af

@bsep: Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concern owner.
Cc: manoranj...@chromium.org
Labels: ReleaseBlock-Stable
Adding release blocker label for this issue.Please reduce priority or remove if not the case.

Thank You!
Cc: gov...@chromium.org

Comment 5 by bsep@chromium.org, Apr 12 2018

Labels: Needs-Feedback
I tested this in 67.0.3395.0 and it doesn't repro for me. Touching the window controls with the hamburger menu open correctly operates them. I tried this in both incognito and regular windows, on a Surfacebook with touch input.

I need more information to investigate.

Comment 6 by vku...@etouch.net, Apr 13 2018

Labels: -Needs-Feedback
With response to comment #5:

Above issue is still reproducible on Windows 10 touch laptop device using latest canary version 67.0.3396.0 (Official Build)

Please refer attached screencast with device information.
Actual_canary_touchdevice.mp4
345 KB View Download

Comment 7 by bsep@chromium.org, Apr 19 2018

Labels: Needs-Feedback
We tried to reproduce this again on our Surfacebook on 68.0.3400.0 using both touch and the pen and the window controls still work fine. So I don't know what we're missing.

Do the window controls work without opening the wrench menu? What happens if you restart the computer before attempting to reproduce the bug? Do you have additional monitors attached? What is the exact hardware and input method you're using (finger, pen, or simulated touch)? I'm thinking there might be some kind of hardware-specific problem.

Comment 8 by vku...@etouch.net, Apr 20 2018

Labels: -Needs-Feedback
With response to comment #7:

Rechecked above issue on Dell (Inspiron 15R) Windows 10 touch device and issue is still reproducible on latest canary #68.0.3401.0 and below are the findings:

1.Yes the window controls work without opening the wrench menu.
2.Issue is still reproducible even after restarting the machine.
3.No additional monitors are attached and we are using Finger as the input method.

Note: We don't have Surfacebook to check the above issue.

Please refer attached screencast

Thank You!
Actual_Canary.mp4
378 KB View Download

Comment 9 by bsep@chromium.org, Apr 20 2018

Labels: -ReleaseBlock-Stable
Not RBS
Labels: -Pri-1 Pri-3
Labels: Hotlist-DesktopUIChecked Hotlist-DesktopUIValid
Mass UI Triage Update:

Still able to reproduce the above issue on Win 10 touch device using latest canary #72.0.3610.0.Please find the screen shot for reference.

@bsep: Could you please take a look into this issue.

Thank you
Canary_Behaviour.mp4
354 KB View Download
Cc: -eirage@chromium.org

Sign in to add a comment