(Unable to narrow down the range using per-revision and old script as the "manage cast devices" page doesn't load in chrome builds,Hence providing the CL)

CL:
https://chromium.googlesource.com/chromium/src/+log/68.0.3437.0..68.0.3438.0?pretty=fuller&n=10000

Suspecting: r560464 ?

@cbiesinger: 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.

Correction: Issue is not seen on Mac OS X(10.12.6,10.13.1,10.13.5) 

marking as RBS, please change if required.

This is a layout problem with the Cast setup UI, which is not part of Chrome itself.

We will file a bug against the relevant Google team and close this out.

Actually the fact that this is Windows specific and there was a layout change makes me believe that we should take a close look at https://crrev.com/560464 first.

cbiesinger@ can you PTAL?

My change was specific to LayoutNG, which is not enabled by default.

(mfoltz, see above)

Blink>Paint can you PTAL?

https://chromium.googlesource.com/chromium/src/+/a5d0643352de46304b2c8b8deeecdc57edc2d860 "Don't fake surface sizes on Mac." seems plausible.

Otherwise nothing jumped out at me from the 400 odd changes in the regression range. Narrowing this down would be really really helpful. Also, does it still reproduce on Canary?

That change only builds on Mac and it shouldn't affect Windows, unfortunately.

+fsamuel, crossing this off the list, I don't think this is surface sync related. Because it looks like the page is still responding to events. If it were some issue with the renderer not getting the correct ID to use, I'd expect the page to stall. Does that sound right?

I'm investigating now to see whether this is surface sync related.

Friendly ping to get an update as it is marked as RBS.
Thanks..!

fsamuel@chromium.org: any updates on this?

ligi@: is it still possible to do a manual bisect on this to help speeding up resolving the issue?

Please provide per revision bisect,  non blocker unless we have the right bisects.

nyerramilli@ to make this happen.

With respect to comment #15.

Using the per-revision bisect providing the bisect results,
GGood Build: 68.0.3437.0(Revision:560454)
Bad Build: 68.0.3438.0(Revision:560883)

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

CHANGE-LOG URL:
---------------
https://chromium.googlesource.com/chromium/src/+log/65421f69a6e0e69991c3d6521f98efa8647b547f..0d7d74584f957455326b334f3476be4720b70353

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

@fsamuel: 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.

Reviewed-on:https://chromium-review.googlesource.com/1055470

This was fixed a while ago and merged back into M68:

https://chromium-review.googlesource.com/c/chromium/src/+/1099515

[Auto-generated comment by a script] We noticed that this issue is targeted for M-68; it appears the fix may have landed after branch point, meaning a merge might be required. Please confirm if a merge is required here - if so add Merge-Request-68 label, otherwise remove Merge-TBD label. Thanks.

Already merged per #19.