Correction:
Good Build: 56.0.2907.0
Bad Build:  56.0.2908.0

Using the per-revision bisect providing the bisect results,
Good Build: 56.0.2907.0 (Revision : 429169)
Bad Build:  56.0.2908.0 (Revision : 429486)

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

CHANGELOG URL:

 https://chromium.googlesource.com/chromium/src/+log/be10da649c394e30378885e6b73d75257aa2aff5..3347bb8ad251e778ed35c433c0246e0659f2402d

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

@mlamouri - 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/2470503003

Thanks!

We are close to M56 stable release , please get this resolved ASAP.

Just to update, still able to reproduce on mac 10.12.2 using latest canary #57.0.2983.0.

mlamouri@ - As it has been marked as a stable blocker, could you please have a look into this issue.

Thanks...!!

I tried to reproduce on 56.0.2924.51 and wasn't able to.

Also, given the STR, I wouldn't call this a RBS.

With response to comment #5, able to reproduce above issue on 56.0.2924.59.
Please find the attached video.

Deleted: Actual_video.mp4 580 KB

	Actual_video.mp4 580 KB View Download

As per #5 removing RBS.

I was able to reproduce finally but this is slightly random, this is why I had a hard time.

As it appear, it is very similar to  bug 663680  but when leaving fullscreen. What happens is that the two other videos receive a layout with a screen available size smaller than the size of the video so they repaint the controls. Sometimes, they never receive a layout when the final size is reached. The other happened when a video was going fullscreen. In this case, the issue is on other videos when they leave fullscreen.

I can't think of any simple workaround this time so I'm assigning to foolip@. It would be great to have entering/leaving fullscreen properly send layouts after the transition.

Just to Update,Still able to reproduce the issue on Mac 10.12.2 using latest chrome version 58.0.2992.0.

Foolip@ Could you please look into this issue.

Thanks!

Sorry, I've had some fullscreen-related release blocker regressions caused by my CLs, so I haven't looked into this yet.

https://codereview.chromium.org/2470503003 landed before all of my recent fullscreen changes, and fullscreen is indeed very strange when it comes to layout. Issues like this may be swept away by  issue 240576  so unless caused by me, I think it's better for me to prioritize that. Assigning back to mlamouri@ with some questions for investigation.

In the video in #7, is device emulation being used, or why is there so little space? Is it in the first layout after entering fullscreen that the controls get resized to this size? At that time, what is the layout width of the video element itself? After exiting fullscreen, is the size of the video element unchanged? If yes, then its children should not need another layout. If no, then does the controls layout make any sense given that size?

Just from the video, the controls just seems much smaller than they should ever have to be. It's possible that there is a scale problem involved here, that the page scale changes when entering and exiting fullscreen, and that code for calculating controls size does not take that into account. If so, then I don't think that  issue 240576  will accidentally fix this, and triggering more layout invalidation may hide the problem but not fix it.

jshanbal@,
Seems issue working as expected in latest Canary-58.0.3018.0.Could you please check & update the thread accordingly.

Thank you!!

With response to comment #13, above issue is fixed on latest Canary version: 58.0.3025.0