Attaching video and screenshots for reference..

Deleted: Actual_hangouts.ogv 2.9 MB

	Actual_hangouts.ogv 2.9 MB View Download

Deleted: Expected_hangouts share screen chopped.png 305 KB

	Expected_hangouts share screen chopped.png 305 KB View Download

Deleted: Actual_chopped.png 367 KB

	Actual_chopped.png 367 KB View Download

Unable to reproduce the issue on Ubuntu 14.04 and Mac 10.11.6 using 57.0.2946.0, may be network issue.

Issue is reproducilble using a lesser screen sizeed window Ubuntu 14.04(Lenovo X1 Carbon) using Dev # 57.0.2948.0.

Please find the screen cast and below steps for easy repro:

Open hangouts(from gmail):
1) Initiate a video call
2) Doobble click on video to go full screen(not necessary to be joined by the recipient) 
3) Doubble click again to come out of full screen
4) Observe the video shifted to the right with a black screen to the left pane of Video call

Deleted: Hangout issue.webm 8.2 MB

	Hangout issue.webm 8.2 MB View Download

Issue is reproducible in both scenarios i.e; video call using gmail/ video call through https://hangouts.google.com link in CrOS using chrome version 57.02948.0/9075.0.0.

Using the per-revision bisect providing the bisect results,
Good Build: 57.0.2943.0 dev (Revision :436483)
Bad Build: 57.0.2944.0 dev (Revision :436816)

You are probably looking for a change made after 436584 (known good), but no later than 436585 (first known bad).
CHANGELOG URL:
The script might not always return single CL as suspectas some perf builds might get missing due to failure.
 https://chromium.googlesource.com/chromium/src/+log/1a49d60bd22ef9ccb97619ba3441bbd89f4b0c3e..a2441f293224a5c5c0352f40c5e8fcbbf1a5a051

From the CL above, assigning the issue to the concern owner 

@foolip - 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.

Review-Url: https://codereview.chromium.org/2550703002

Thanks!

Marking this as Blocker as this is recent regression.

 Issue 674464  has been merged into this issue.

I've tried to reproduce this problem but no matter where I double click that doesn't trigger fullscreen. In the source of hangouts.google.com, searching with devtools I can't find and webkitRequestFullscreen, requestFullscreen, or anything else that could enter fullscreen.

Maybe some scripts are loaded on-demand, but when? Added Needs-TestConfirmation label.

Tested on Windows 7 & Ubuntu 14.04 with chrome latest Canary version# 57.0.2955.0 as per the steps mentioned in Comment#3 ,still we are able to reproduce the issue.

Note:Please try with non-google account to reproduce the issue .Issue can not be reproduced with Corp account as on double click that doesn't trigger fullscreen.

Thank you.

Removing Needs-TestConfirmation as Issue is updated with information in C#9.

Just to update, still able to reproduce the issue on windows-7 and Linux Ubuntu-14.04 using chrome latest canary 57.0.2971.0 

foolip@ could you please look into this issue.

Thanks,

 Issue 678571  has been merged into this issue.

foolip@: Could you please take a look at this as per C#9.

I am able to reproduce this on Linux Ubuntu-14.04 using Chrome 57.0.2979.0 using a non-corp account. However, it takes many cycles of going in and out of Fullscreen to see the problem.

When the problem does happen, a container element appears to be in the wrong position. Its (relevant) specified style is { position: absolute; right: 0; width: 100vw }, the computed style is { position: absolute; right: 0px; width: 1490px } and getBoundingClientRect() is {top: 0, right: 2560, bottom: 1000, left: 1070, width: 1490 }.

My screen is 2560px and the window size (when not in fullscreen) is 1490px, and 1490+1070=2560. The calculation of vw appears to be correct as the width is 1490, but somehow right:0 has been treated as 2560.

nduca@, this is the reason I asked you about tracing on https://www.chromium.org/developers/how-tos/trace-event-profiling-tool/frame-viewer

I'm thinking that if I can record what frame the renderer is producing, I might be able to tell if the bad frame first happens right before or right after exiting fullscreen. Unfortunately, whatever I've tried I can't see a cc:Picture in any trace I've made.

FWIW, I have used per-commit bisects of official Chrome builds (internal only) to verify that my commit really is to blame. Because of the flaky nature of the repro, I had to test a lot to be confident of this, and at one point it looked like a skia roll was to blame, but it wasn't so.

This issue can actually be reproduced without the use of screen sharing:
1. Go to hangouts.google.com with a non-corp account
2. Call anyone. It doesn't seem to matter if they decline or leave it ringing.
3. Double click frantically to enter and exit fullscreen.

Once in a while, after exiting fullscreen, the page will be (almost) black. One can tell at the top that there's a dark gray gradient where the content actually starts, which is green when screen sharing and then much more obvious.

I have found the cause and a fix for this. In FullscreenController::updateSize(), the switch from using isFullscreen() to m_state != State::Fullscreen for the early return means that the early return is taken while exiting fullscreen. The old defintion of isFullscreen() was true while exiting, and the code depends on this.

I will send out a fix for this once I've handled a more urgent M-56 regression,  issue 668969  and  issue 677827 .

https://codereview.chromium.org/2652763011 is the smallest possible fix, will send out for review soonish.

Repro steps are even simpler:
1. Go to hangouts.google.com with a non-corp account
2. Click "Video Call" which will open a new window.
3. Dismiss the dialog to invite someone to the call.
4. Double click to enter and exit fullscreen repeatedly.

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

commit 60d7317f407f575a17410c1a05f52f1ee4941d0c
Author: foolip <foolip@chromium.org>
Date: Wed Jan 25 18:31:03 2017

Call LayoutFullScreen::updateStyle() when exiting Fullscreen

https://codereview.chromium.org/2550703002 changed the definition of
FullscreenController::isFullscreen. Previously, by using
m_fullscreenFrame, it would return true from having entered fullscreen
to having exited fullscreen, i.e. also while exiting. It was changed to
only return true while properly in fullscreen.

This difference turned out to matter, as a call to
LayoutFullScreen::updateStyle() in FullscreenController::updateSize() is
no longer made.

In hangouts.google.com, this broke the layout upon exiting fullscreen.

TEST=https://bugs.chromium.org/p/chromium/issues/detail?id=672804#c21

A regression test for this has proven difficult. With or without the
change, there is a LayoutObject::assertLaidOut() failure upon exiting
fullscreen, which is most likely related to LayoutFullScreen. Yet, it
appears that a non-trivial layout is required to reproduce, which would
require minimizing hangouts.google.com into a test case.

LayoutFullScreen and thus the updateStyle() call is slated for full
removal with top layer ( issue 240576 ) so this does not seem like a good
use of time. Instead, an issue to re-check for failing assertLaidOut()
after top layer has landed was filed:  https://crbug.com/685068 

BUG= 672804 

Review-Url: https://codereview.chromium.org/2652763011
Cr-Commit-Position: refs/heads/master@{#446062}

[modify] https://crrev.com/60d7317f407f575a17410c1a05f52f1ee4941d0c/third_party/WebKit/Source/web/FullscreenController.cpp

foolip@ has this CL been validated on ToT yet?

ketakid@, no, I added the label as soon as it had landed, as I assumed merge requests this soon after branch would be auto-approved so I could handle that myself with the approval in hand. I can wait for the next Canary and report back.

Your change meets the bar and is auto-approved for M57. Please go ahead and merge the CL to branch 2987 manually. Please contact milestone owner if you have questions.
Owners: amineer@(clank), cmasso@(bling), ketakid@(cros), govind@(desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

If possible, pls merge your change to M57 branch 2987 before 5:00 PM PT today (Thursday, 01/26) so we can pick it for tomorrow's Dev release.

I have verified the fix in Chrome Canary, now merging.

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

commit c3055f3d690fd3d9a4a905cf705c145609714a0a
Author: Philip Jägenstedt <foolip@chromium.org>
Date: Fri Jan 27 06:34:17 2017

Call LayoutFullScreen::updateStyle() when exiting Fullscreen

https://codereview.chromium.org/2550703002 changed the definition of
FullscreenController::isFullscreen. Previously, by using
m_fullscreenFrame, it would return true from having entered fullscreen
to having exited fullscreen, i.e. also while exiting. It was changed to
only return true while properly in fullscreen.

This difference turned out to matter, as a call to
LayoutFullScreen::updateStyle() in FullscreenController::updateSize() is
no longer made.

In hangouts.google.com, this broke the layout upon exiting fullscreen.

TEST=https://bugs.chromium.org/p/chromium/issues/detail?id=672804#c21

A regression test for this has proven difficult. With or without the
change, there is a LayoutObject::assertLaidOut() failure upon exiting
fullscreen, which is most likely related to LayoutFullScreen. Yet, it
appears that a non-trivial layout is required to reproduce, which would
require minimizing hangouts.google.com into a test case.

LayoutFullScreen and thus the updateStyle() call is slated for full
removal with top layer ( issue 240576 ) so this does not seem like a good
use of time. Instead, an issue to re-check for failing assertLaidOut()
after top layer has landed was filed:  https://crbug.com/685068 

BUG= 672804 

Review-Url: https://codereview.chromium.org/2652763011
Cr-Commit-Position: refs/heads/master@{#446062}
(cherry picked from commit 60d7317f407f575a17410c1a05f52f1ee4941d0c)

Review-Url: https://codereview.chromium.org/2653923006 .
Cr-Commit-Position: refs/branch-heads/2987@{#135}
Cr-Branched-From: ad51088c0e8776e8dcd963dbe752c4035ba6dab6-refs/heads/master@{#444943}

[modify] https://crrev.com/c3055f3d690fd3d9a4a905cf705c145609714a0a/third_party/WebKit/Source/web/FullscreenController.cpp

Verified this issue on Windows-10, Ubuntu 14.04 and Mac OS 10.12 using chrome latest Dev M57-57.0.2987.19 by following steps mentioned in the original comment and observed no black space is seen on exiting the full screen from google hangout. Hence adding TE-Verified label.

Thanks!

Deleted: 672804.jpg 148 KB

	672804.jpg 148 KB View Download