I also hit the same problem, it worked before but now it doesn't. API call makes browser freeze, but this happens only on Windows, Linux (Ubuntu 16.04LTS) and OSX 10.13 (High Sierra) it works well.

Bisect info: 415196 (good) - 415228 (bad)
https://chromium.googlesource.com/chromium/src/+log/9a8f5c73..5eb32ca6?pretty=fuller
Suspecting r415199 = e7a9525b5e292c45f8d6db8091afed4ea5045aff = https://crrev.com/2270543003 by qiangchen@chromium.org
"Display Window Icon In Picker UI"
Landed in 55.0.2845.0

Repro:
1. suspend some process:
   a. run notepad or calc
   b. unpack and run "Process Explorer"
      https://docs.microsoft.com/en-us/sysinternals/downloads/process-explorer
   c. right-click notepad or calc in the list and choose "Suspend"
2. unpack and load as an unpacked extension:
   https://developer.chrome.com/extensions/examples/api/desktopCapture.zip
3. open chrome://apps/ and run "Desktop Capture Example"
4. click "Start"

Expected: a window opens with a screenshot inside
Observed: Chrome becomes totally unresponsive

Able to reproduce the issue on reported chrome version #70.0.3538.110 and latest chrome #73.0.3629.0 using Windows 7 by following steps as per comment#2.
Note: Unable to check the issue on Linux and Mac OS

The behavior is observed from M-60(#60.0.3112.113). This is non-regression issue hence marking it as untraiged and requesting someone from the dev team to look into the issue.
Thanks.!

Corrected scenario:
1. Start Chrome (v. 70) with flags (order is important)
    --auto-select-desktop-capture-source="Entire screen" --enable-usermedia-screen-capturing
2. Install extension https://chrome.google.com/webstore/detail/jitsi-meetings/kglhbbefdnlheedjiejgomgmfplipfeb?utm_source=inline-install-disabled
3. Start meeting on http://meet.jit.si/
4. Start screensharing (left bottom button). If first attempt was successful, stop screensharing and start it again.

Expected: every time user starts sharing browser automatically starts sharing for entire screen.
Observed: Chrome hangs when trying to display selection window and hide it automatically.

niklase/emircan can you take a look?

I can't repro this on my Windows machine(Win 10 Lenovo P50) using steps in #6. braveyao@ can you also give it a try if you have a Win machine available?

The CL found in #2 a week ago makes the cause of the bug quite obvious, I think. Chrome shouldn't try to get icons from unresponsive processes. So the only problem here is how to detect it in WINAPI. Or simply add a timeout and kill the icon fetching thread forcibly.

I see. #2 and #6 are actually different issues then?

I think the reporter probably wanted to make a more realistic repro scenario so it's the same but you need to have a nonresponsive process, for example by suspending it in Process Explorer as shown in #2.

I suppose #6 is irrelevant and can't reproduce with it. Besides those flags are for test purpose only.

I can reproduce as #2 indicates. And the reason is as #10 shows. Trying to search around for a solution. 

The unresponsive window will hang Chrome not only at getting icon, but also at capturing. So the best way is to exclude it from the list in picker.

There is an API IsHungAppWindow(), which is not for general use(and may be deprecated soon) and doesn't work for the case in #2.
Have to use an alternative to test the target window by send a WM_NULL message. 

Earlier Chrome code noted that IsHungAppWindow() does not correctly deal with suspended. Let's see if there are alternatives.
https://chromium.googlesource.com/chromium/src/+/09911bf300f1a419907a9412154760efd0b7abc3/chrome/browser/hang_monitor/hung_window_detector.h#41

Thanks emircan@!
Got this handled and cl ready.

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

commit 436ef318b320446b6182196c7f0c3422ae350f9e
Author: braveyao <braveyao@chromium.org>
Date: Fri Dec 14 21:22:38 2018

desktopCapture: avoid freezing at getting icon from an unresponsive window

We'll get window icons at starting the picker for each available window.
If there is any app window unresponsive, then the system call will block,
which will freeze the browser too.
This cl is to use SendMessageTimeout instead of original SendMessage, which
will returen when the target window is hung. (PS: we can still get its
icon by GetClassLong().)

Since the unresponsive window can't be captured, there is no need to show
it in the picker. It's reasonable to skip it in the window list, which will
be done in a seperate cl in webrtc.

Bug:  911110 
Change-Id: Ib4e73d75d2012f75d7b969aea855a6de0b88a879
Reviewed-on: https://chromium-review.googlesource.com/c/1378670
Reviewed-by: Emircan Uysaler <emircan@chromium.org>
Commit-Queue: Weiyong Yao <braveyao@chromium.org>
Cr-Commit-Position: refs/heads/master@{#616826}
[modify] https://crrev.com/436ef318b320446b6182196c7f0c3422ae350f9e/chrome/browser/media/webrtc/window_icon_util_win.cc

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

commit b46235c1ccb3d105a6a0f8944c32440c97cd27ce
Author: braveyao <braveyao@webrtc.org>
Date: Fri Jan 11 19:21:22 2019

desktopCapture: skip non-responsive windows in the picker

This is a following up cl to the fix of  crbug.com/911110 . On Windows,
if an App window is suspended, it will block some queries (which
causes Chromium freezing and is fixed in Chromium.) and won't be captured.
So there is no reason to list it in the window capture picker.

Notes: this cl can't fix the case that the select app window becomes
non-responsive just before capturing starts. Hope that an extreme corner
case that can be safely ingored.

Bug:  chromium:911110 
Change-Id: I0d14872ac699d559f40b3bff70f048efc67ca5d9
Reviewed-on: https://webrtc-review.googlesource.com/c/115441
Reviewed-by: Jamie Walch <jamiewalch@chromium.org>
Commit-Queue: Brave Yao <braveyao@webrtc.org>
Cr-Commit-Position: refs/heads/master@{#26230}
[modify] https://crrev.com/b46235c1ccb3d105a6a0f8944c32440c97cd27ce/modules/desktop_capture/window_capturer_win.cc

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

commit 2ba444ba6f708cb3bcb827ee2ac8a7bc4044e03e
Author: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Date: Mon Jan 14 18:56:37 2019

Roll src/third_party/webrtc aaa99a93e288..b2e21b014c3d (10 commits)

https://webrtc.googlesource.com/src.git/+log/aaa99a93e288..b2e21b014c3d


git log aaa99a93e288..b2e21b014c3d --date=short --no-merges --format='%ad %ae %s'
2019-01-14 mbonadei@webrtc.org Remove rtc_enable_android_opensl.
2019-01-11 garykac@chromium.org Set callback_ member at start of desktop capturer Start()
2019-01-11 braveyao@webrtc.org desktopCapture: skip non-responsive windows in the picker
2019-01-11 mbonadei@webrtc.org Rename AttachCurrentThreadIfNeeded to avoid clash with function.
2019-01-11 steveanton@webrtc.org (6) Rename files to snake_case: remove scripts and temp files
2019-01-11 steveanton@webrtc.org (5) Rename files to snake_case: install forwarding headers
2019-01-11 steveanton@webrtc.org (4) Rename files to snake_case: update BUILD.gn, include paths, header guards, and DEPS entries
2019-01-11 steveanton@webrtc.org (3) Rename files to snake_case: move the files
2019-01-11 steveanton@webrtc.org (2) Rename files to snake_case: files to rename
2019-01-11 steveanton@webrtc.org (1) Rename files to snake_case: scripts


Created with:
  gclient setdep -r src/third_party/webrtc@b2e21b014c3d

The AutoRoll server is located here: https://autoroll.skia.org/r/webrtc-chromium-autoroll

Documentation for the AutoRoller is here:
https://skia.googlesource.com/buildbot/+/master/autoroll/README.md

If the roll is causing failures, please contact the current sheriff, who should
be CC'd on the roll, and stop the roller if necessary.

CQ_INCLUDE_TRYBOTS=luci.chromium.try:linux_chromium_archive_rel_ng;luci.chromium.try:mac_chromium_archive_rel_ng

BUG=chromium:916961, chromium:911110 ,chromium:None
TBR=webrtc-chromium-sheriffs-robots@google.com

Change-Id: I2b736403fc1966f0caf6064f7e8c5fea5b68b2a3
Reviewed-on: https://chromium-review.googlesource.com/c/1409091
Reviewed-by: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Commit-Queue: chromium-autoroll <chromium-autoroll@skia-public.iam.gserviceaccount.com>
Cr-Commit-Position: refs/heads/master@{#622538}
[modify] https://crrev.com/2ba444ba6f708cb3bcb827ee2ac8a7bc4044e03e/DEPS