resesek@, what should we do to adapt to the changing of using MessagePumpDefault on OSX in https://chromium-review.googlesource.com/c/chromium/src/+/681850?

+ erikchen@ for more insight of Screencapturer on OSX.

You'll want to adjust the thread that runs this code to use a different MessageLoop type. For an example of a CL that does this for another component, see: https://chromium-review.googlesource.com/c/chromium/src/+/923584

Yes, switching to UI thread will fix this issue, https://cs.chromium.org/chromium/src/content/browser/media/capture/desktop_capture_device.cc?l=576.

Thanks a lot!

Erik's right with #4. But also see  issue 827300 .

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

commit 18b6eee163f276a6023f51a68b7b8e71328b748e
Author: braveyao <braveyao@chromium.org>
Date: Fri Apr 27 04:18:37 2018

[Mac] Force a MessageLoop::TYPE_UI for the desktopCaptureThread

In a recent CL, https://chromium-review.googlesource.com/c/chromium/src/+/681850,
MesasgePumpDefault is used for MessageLoop::TYPE_DEFAULT on OSX.
This requests the desktopCaptureThread to be adjusted to run as
a UI thread, otherwise the CFRunLoop won't run again after
display resolution changes.

Bug:  836978 
Change-Id: Ifb460f19dca4741359d93bb73e280404d62c5a05
Reviewed-on: https://chromium-review.googlesource.com/1029113
Reviewed-by: Zijie He <zijiehe@chromium.org>
Commit-Queue: Weiyong Yao <braveyao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#554299}
[modify] https://crrev.com/18b6eee163f276a6023f51a68b7b8e71328b748e/content/browser/media/capture/desktop_capture_device.cc

Tested this issue on MacBook Pro 10.13.3 on the build without fix 68.0.3406.0 and the build with fix 68.0.3415.0.
Unable to reproduce the issue on the build without fix by following the steps given in the original comment.

Able to share the screen via Hangouts and no hang is observed when the screen resolution is changed.
Tried changing the resolution in System Preferences as well and no freeze is observed on the screen.

Attached is the screen cast for reference.

braveyao@ Request you to check and confirm if anything is missed from our end in testing the issue.
Also help us in verifying the fix on the latest M-68 68.0.3415.0 build.

Thanks...

Deleted: 836978.mp4 10.3 MB

	836978.mp4 10.3 MB View Download

Thanks susan.boorgula@ for the verification! Seems that I didn't make myself clear in the original report, that it's the video stream freezes, not the App/Page. 

Verified on Mac with Canany 68.0.3414.0.

This bug requires manual review: M67 has already been promoted to the beta branch, so this requires manual review
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), kbleicher@(ChromeOS), govind@(Desktop)

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

Before we approve merge to M67, please answer followings:
* Is this M67 regression? Is it critical?
* Is the change well baked/verified in Canary, having enough automation tests coverage and safe to merge to M67?
* Any other important details to justify the merge.

Please note M67 is already in Beta, so merge bar is VERY high. Thank you

- This is a regression happened in this Feb. It's not so critical itself, but it blocks the fix for  issue 836979 .
- Yes. It's verified in Canary.
- Several other CL have been landed due to the regression. For example  issue 827300 .

Thank you  braveyao@.

Only Cl listed at #7 need a merge to M67 and it is a fully safe merge?

Yes, that's true.

Oh, the example for  issue827300  only shows that this is a safe fix and will be a safe merge, which did the same thing in #7 here.

Approving merge for CL listed at #7 to M67 branch 3396 based on comments #13 and #15. Please merge ASAP. 

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

commit 586a16d084f4c0a4a467914399a2b0cd1be29ac5
Author: braveyao <braveyao@chromium.org>
Date: Mon Apr 30 19:43:45 2018

[Mac] Force a MessageLoop::TYPE_UI for the desktopCaptureThread

In a recent CL, https://chromium-review.googlesource.com/c/chromium/src/+/681850,
MesasgePumpDefault is used for MessageLoop::TYPE_DEFAULT on OSX.
This requests the desktopCaptureThread to be adjusted to run as
a UI thread, otherwise the CFRunLoop won't run again after
display resolution changes.

Bug:  836978 
Change-Id: Ifb460f19dca4741359d93bb73e280404d62c5a05
Reviewed-on: https://chromium-review.googlesource.com/1029113
Reviewed-by: Zijie He <zijiehe@chromium.org>
Commit-Queue: Weiyong Yao <braveyao@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#554299}(cherry picked from commit 18b6eee163f276a6023f51a68b7b8e71328b748e)
Reviewed-on: https://chromium-review.googlesource.com/1035963
Reviewed-by: Weiyong Yao <braveyao@chromium.org>
Cr-Commit-Position: refs/branch-heads/3396@{#393}
Cr-Branched-From: 9ef2aa869bc7bc0c089e255d698cca6e47d6b038-refs/heads/master@{#550428}
[modify] https://crrev.com/586a16d084f4c0a4a467914399a2b0cd1be29ac5/content/browser/media/capture/desktop_capture_device.cc

Re-Tested this issue on MacBook Pro 10.13.3 on the build without fix 68.0.3410.0 and unable to reproduce the issue.
Able to share the screen via Hangouts and no video freeze is observed when the screen resolution is changed.

braveyao@ Request you to check and help us in verifying the fix on the latest M-67 67.0.3396.30 build.

Thanks..

M-67 67.0.3396.30 works fine now.

[bulk-edit: disregard if N/A] Can the owner please set milestone to this bug if applicable?