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

Issue 875731 link

Starred by 3 users

Issue metadata

Status: Fixed
Owner:
Closed: Aug 21
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 1
Type: Bug-Regression



Sign in to add a comment

Regression: Omnibox becomes Unresponsive after exiting the window from fullscreen

Reported by khushal....@etouch.net, Aug 20

Issue description

Chrome Version: 70.0.3528.0 (Official Build) Revision 354e37b4e7e3c9faacf4837f19c2ff88d6e61dda-refs/branch-heads/3528@{#1} (64 bit)
OS: Mac (10.12.6, 10.13.1, 10.13.6, 10.14)

What steps will reproduce the problem?
(1) Fresh Launch Google Chrome and press "Ctrl+Cmd+F" (or Green Traffic Signal button) to fullscreen the window.
(2) Now again press "Ctrl+Cmd+F" (or Green Traffic Signal button) to exit the fullscreen and try to click in Omnibox.
(3) Observe.

Actual Result: Omnibox becomes Unresponsive after exiting the window from fullscreen.

Expected Result: Omnibox should respond properly after exiting the window from fullscreen.

This is a Regression issue seen from 'M-70' and providing the bisect info below:
Good Build: 70.0.3526.0 (Revision: 584273)
Bad Build:  70.0.3527.0 (Revision: 584327)

You are probably looking for a change made after 584307 (known good), but no later than 584308 (first known bad).

CHANGE-LOG 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/7f48b3540a8dd9e759fc592cb6ec895fed46b3d8..78a0d81fb18f78c01c6b2b3908c9e4f4d13dc97e

Suspect: https://chromium.googlesource.com/chromium/src/+/78a0d81fb18f78c01c6b2b3908c9e4f4d13dc97e

@ccameron: 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: Issue is not seen on Win (7, 8, 8.1, 10) & Linux (14.04 LTS) OS.

Kindly refer the attached screen-cast.

Thank You..!!

 
Actual Video.mov
9.5 MB View Download
Expected Video.mov
10.0 MB View Download
Cc: abdulsyed@chromium.org ligim...@chromium.org
Labels: ReleaseBlock-Dev
marking as RBD, please change if required.
Labels: -ReleaseBlock-Dev ReleaseBlock-Beta Proj-MacViews
Guessing this is due to Mac views, Chris could you please take a look into this bug.
Have a fix ready.
great, can it be merged to today's canary as well? branch: 3528

We'll use this for our dev candidate tomorrow, and it'll be great to have the fix in. 
Yes -- https://chromium-review.googlesource.com/c/chromium/src/+/1181926 is reviewed, but the CQ is hosed.
Chris, we already triggered Dev RC, we can take this patch for next release. Meanwhile once the fix lands test team can verify.
I think this bug should block Dev release -- it's pretty bad.
Labels: ReleaseBlock-Dev
I agree - let's get it merged to 3528. I can re-trigger it once it's merged. 
Cc: ccameron@chromium.org
 Issue 875776  has been merged into this issue.
Project Member

Comment 11 by bugdroid1@chromium.org, Aug 20

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f2bae22e479aaca78d061b379bead022dd5acd40

commit f2bae22e479aaca78d061b379bead022dd5acd40
Author: Christopher Cameron <ccameron@chromium.org>
Date: Mon Aug 20 23:22:37 2018

RemoteMacViews: Ensure window and view updates are synchronized

When updating the views::View size, ensure that the NSWindow size be
updated first (otherwise we end up with strange mismatches). Add a
TODO about merging methods here.

This requires access to the BridgedNativeWidget from
BridgedContentView, so make BridgedNativeWidget store a pointer to
BridgedContentView (from which it can access BridgedContentViewHost),
rather than storing a pointer to BridgedContentViewHost. Also change
one instance where we pulled the BridgedContentView from the NSWindow
to use the pointer directly.

Bug:  875776 ,  875731 
Change-Id: Ia9c3d4238f6824e5595baa5d4e856c34ead0fb75
Reviewed-on: https://chromium-review.googlesource.com/1181926
Commit-Queue: ccameron <ccameron@chromium.org>
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Cr-Commit-Position: refs/heads/master@{#584582}
[modify] https://crrev.com/f2bae22e479aaca78d061b379bead022dd5acd40/ui/views/cocoa/bridged_content_view.h
[modify] https://crrev.com/f2bae22e479aaca78d061b379bead022dd5acd40/ui/views/cocoa/bridged_content_view.mm
[modify] https://crrev.com/f2bae22e479aaca78d061b379bead022dd5acd40/ui/views/cocoa/bridged_native_widget.h
[modify] https://crrev.com/f2bae22e479aaca78d061b379bead022dd5acd40/ui/views/cocoa/bridged_native_widget.mm

Project Member

Comment 12 by bugdroid1@chromium.org, Aug 21

Labels: merge-merged-3528
The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/917518a286adb36cd3e7ccff6cdbe6e733539ec3

commit 917518a286adb36cd3e7ccff6cdbe6e733539ec3
Author: Christopher Cameron <ccameron@chromium.org>
Date: Tue Aug 21 00:00:02 2018

RemoteMacViews: Ensure window and view updates are synchronized

When updating the views::View size, ensure that the NSWindow size be
updated first (otherwise we end up with strange mismatches). Add a
TODO about merging methods here.

This requires access to the BridgedNativeWidget from
BridgedContentView, so make BridgedNativeWidget store a pointer to
BridgedContentView (from which it can access BridgedContentViewHost),
rather than storing a pointer to BridgedContentViewHost. Also change
one instance where we pulled the BridgedContentView from the NSWindow
to use the pointer directly.

TBR=ccameron@chromium.org

(cherry picked from commit f2bae22e479aaca78d061b379bead022dd5acd40)

Bug:  875776 ,  875731 
Change-Id: Ia9c3d4238f6824e5595baa5d4e856c34ead0fb75
Reviewed-on: https://chromium-review.googlesource.com/1181926
Commit-Queue: ccameron <ccameron@chromium.org>
Reviewed-by: Elly Fong-Jones <ellyjones@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#584582}
Reviewed-on: https://chromium-review.googlesource.com/1182582
Reviewed-by: ccameron <ccameron@chromium.org>
Cr-Commit-Position: refs/branch-heads/3528@{#8}
Cr-Branched-From: 2d67fa3c43ccc16edae0a742d902dd437795959b-refs/heads/master@{#584349}
[modify] https://crrev.com/917518a286adb36cd3e7ccff6cdbe6e733539ec3/ui/views/cocoa/bridged_content_view.h
[modify] https://crrev.com/917518a286adb36cd3e7ccff6cdbe6e733539ec3/ui/views/cocoa/bridged_content_view.mm
[modify] https://crrev.com/917518a286adb36cd3e7ccff6cdbe6e733539ec3/ui/views/cocoa/bridged_native_widget.h
[modify] https://crrev.com/917518a286adb36cd3e7ccff6cdbe6e733539ec3/ui/views/cocoa/bridged_native_widget.mm

Labels: TE-Verified-M70 TE-Verified-70.0.3529.3 TE-Verified-70.0.3528.4
Update:

Rechecked the issue on Mac (10.12.6, 10.13.1, 10.13.6, 10.14) using latest build #70.0.3528.4 and #70.0.3529.3 and the issue is found FIXED.

Thank you..!!
Fixed_70.0.3528.4.mov
10.7 MB View Download
Fixed_70.0.3529.3.mov
10.2 MB View Download
Chris, can we close this issue?
Status: Fixed (was: Assigned)
Friendly ping to get an update as per C#14.
Thanks.!
Yes, this can be closed.

Sign in to add a comment