Manual bisect range:
Good Build:66.0.3335.0(Revision: 533165)
Bad Build: 66.0.3336.0(Revision: 533409)

You are probably looking for a change made after 533390 (known good), but no later than 533392 (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/34977ddf86641e1c2c02d728e7c569c1af9cb3b8..4adaab615822018cddf21a359677e9fdae1d63e9

Suspect: https://chromium.googlesource.com/chromium/src/+/818e182ca6da2b0eee55994b374723eec00b908e

@foolip: Please help me to reassign this issue if your change is not cause for it.

Note: issue is also seen on 'M66' Beta (# 66.0.3359.33)

marking as RBS, please change if required.

Just to update:

Above issue is still reproducible on latest canary build #67.0.3379.0

Kindly refer attached screencast for the same.

Thank you.

Deleted: Actual_issue.mp4 1.0 MB

	Actual_issue.mp4 1.0 MB View Download

This is very similar to  issue 805392 , in that it involves the feedback feature when in fullscreen.

I am unable to reproduce this on Mac. One important difference is that I can't exit fullscreen fast enough for the screenshot to be "waiting" (blue spinner) and in the videos it's a second or so after the screenshot appears that the size changes.

dbote@, can you please check whether you are seeing this issue consistently on Mac OS X? also can you comment on c#5?

with respect to comment 5 & 6:

Issue is reproducible on Mac OS using latest canary build #67.0.3386.0 

Note: To reproduce issue, Before pressing Tab key let the screenshot(shown on feedback overlay) load properly. 

Kindly refer the attached video for the same.

Deleted: Actual_Issue.mov 7.3 MB

	Actual_Issue.mov 7.3 MB View Download

Just a heads up, M66 Stable cut is on April 12th, 10 days away. This issue is marked as RB-Stable for 66. Please make sure to address this issue prior to stable cut. Thanks! 

Friendly ping to get an update on this issue as it is marked as stable blocker & M66 Stable cut is on April 12th.

Thanks..! 

Since this bug (like  issue 805392 ) is only possible to reproduce due to a seemingly broken "Send Feedback" button when in fullscreen, I've filed an internal bug (b/77792105) about that.

Reminder: Please note that M66 Stable is only 7 days away. This bug has been marked as ReleaseBlock Stable for M66. So please take a look and appropriately address this bug. 

Marked as ExternalDependency since I believe the best fix for this would be in b/77792105. The web-exposed behavior has changed, but it seems to me that the existing UI on https://play.google.com/store/movies doesn't make sense, that triggering this is not easy, and that there's very likely a fix for this in https://play.google.com/store/movies itself.

That being said, I will try to reduce this to a test case. That's very timeconsuming for a complex site like this, so I'll also ping the internal bug to see if I can get help to understand what the code is trying to do.

Outcome of b/77792105 is that from Play Movies' point of view, the bug that I fixing this UI isn't a release blocker for them, that "it's just another minor full-screen bug" and "should also be a rare corner case."

Moving this back to assigned to see if I can minimize it to see if there is a bug here, but given the above I don't think the regression is serious enough to be a release blocker, and that reverting it would be worse than not reverting, since the original problem it fixed,  issue 787867 , was worse.

Will keep looking tomorrow, but if this gets human release process attention, I think the right action is to remove ReleaseBlock-Stable and target 68.

This change has now reach M66, and I have not seen reports of breakage outside of play.google.com. Since that issue has been reported internally and is at root (IMHO) a UI bug, I'll close this bug without digging deeper to find out exactly what the root cause was. My very strong suspicion is that when pressing tab in fullscreen, the element to which focus moves is different before and after the change, because that was part of the intended change. That difference triggers some difference in the web app logic, which has been reported and low priority to fix.