Thank you for reporting this issue.
We enabled a new backend on Windows recently, and this problem should be the new backend specific.

Could you try it with chrome://flags/#enable-midi-manager-dynamic-instantiation Disabled on Stable channel?

Also, could you share more information about your MIDI device?
New backend monitors device configuration change events to realize MIDI hotplug on Windows because Windows MIDI API does not provide such interface. But unfortunately, some MIDI devices continue to appear on a Windows API to enumerate MIDI devices for a while even after the device is disconnected. This time lag seems to be device dependent.

At this point, I notice that "ZOOM MS-50G" causes this problem very often.

Also, the lag may depends on Windows version. Could you clarify minor version of Windows 10 that you can find with winver.exe. The version should be something like 1703 that is the number of Creators Update.

Oops, #1 was commented by my personal account.

Hi - thanks for the information.
My Windows build version is 14393.1198 (i.e. pre-Creators Update).
The hardware we've tried is an M-Audio Keystation Mini 32 controller, and a Marshall CODE 25 digital amp.
Changing the MIDIManager flag to disabled does seem fix the issue - I'll do some more testing tomorrow to check that nothing else is affected.
Is the default for this setting something that is likely to be updated in a new Chrome release, and if so do you have any idea of timescales?
Thanks.

Thank you for providing more feedback. Adding requester "toyoshim@chromium.org" to the cc list and removing "Needs-Feedback" label.

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

I've done some more testing of midi after setting the midi manager flag to disabled, and everything seems to be working ok.

On your machine, did the problem happen with all MIDI devices you had?

In another report, the problem happens only with with ZOOM MS-50G, and other devices work fine with his machine. Also he says the windows is pre-Creators Update.

I have one M-Audio keyboard at home though it's a different product. But it would worth trying. Let me try.

A fix is under review. This could happen on MIDI input devices, that may depend on device driver implementation, and Win32 API internal behavior that may differ on recent versions.

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

commit 8f7cc644d6f5c422e32a8886fa58a2e3b5c059ee
Author: Takashi Toyoshima <toyoshim@chromium.org>
Date: Thu Jun 01 14:02:29 2017

Web MIDI: fix a deadlock issue on unloading some input devices

After disconnecting some input devices, the next midiInGetNumDevs()
call invokes a callback with MIM_LONGDATA for the disconnected device,
and never returns until the callback completes.
This is unexpected control dependency, and causes a deadlock.

BUG= 725448 

Change-Id: I39733e4df31223de8f2b7f8e031711496e10ff4a
Reviewed-on: https://chromium-review.googlesource.com/519083
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Commit-Queue: Takashi Toyoshima <toyoshim@chromium.org>
Cr-Commit-Position: refs/heads/master@{#476273}
[modify] https://crrev.com/8f7cc644d6f5c422e32a8886fa58a2e3b5c059ee/media/midi/midi_manager_win.cc

Your change meets the bar and is auto-approved for M60. Please go ahead and merge the CL to branch 3112 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), josafat@(ChromeOS), bustamante@(Desktop)

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

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

commit bc288350e64bb6e17759f3a409b9406f89af9e0b
Author: Takashi Toyoshima <toyoshim@chromium.org>
Date: Sat Jun 03 09:50:45 2017

Web MIDI: fix a deadlock issue on unloading some input devices

After disconnecting some input devices, the next midiInGetNumDevs()
call invokes a callback with MIM_LONGDATA for the disconnected device,
and never returns until the callback completes.
This is unexpected control dependency, and causes a deadlock.

BUG= 725448 

(cherry picked from commit 8f7cc644d6f5c422e32a8886fa58a2e3b5c059ee)

Change-Id: I39733e4df31223de8f2b7f8e031711496e10ff4a
Reviewed-on: https://chromium-review.googlesource.com/519083
Reviewed-by: Yutaka Hirano <yhirano@chromium.org>
Commit-Queue: Takashi Toyoshima <toyoshim@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#476273}
Reviewed-on: https://chromium-review.googlesource.com/523345
Reviewed-by: Takashi Toyoshima <toyoshim@chromium.org>
Cr-Commit-Position: refs/branch-heads/3112@{#132}
Cr-Branched-From: b6460e24cf59f429d69de255538d0fc7a425ccf9-refs/heads/master@{#474897}
[modify] https://crrev.com/bc288350e64bb6e17759f3a409b9406f89af9e0b/media/midi/midi_manager_win.cc

The issue was fixed on m61 and the fix is merged to m60.

I guess merging this to m59 would not meat the bar.

 Issue 732650  has been merged into this issue.

 Issue 733368  has been merged into this issue.

Let me keep this bug open until m60 goes to the Stable so that users can find this existing bug entry to know current status.

The problem is already fixed, and the fix was merged to beta branch. On the stable channel, the problem should be fixed at Chrome 60.

Just to clarify, is this the following bug?

 1. request MIDIAccess
 2. listen to "statechange" on MIDIAccess
 3. turn on MIDI device -> "statechange" fires
 4. listen to "midimessage" on an input port of MIDIAccess
 5. turn off MIDI device -> "statechange" does NOT fire, but it should
 6. try to close tab, chrome freezes completely

Strangely though, this bug appeared in Chrome 59 for us, there were no issues in 58.

Yes - that's the problem that we experienced.
We know that it worked in 58.0.3029.89, but first noticed it had a problem in 58.0.3029.110 - I'm not sure about any intermediate versions.

#18
Yes, exactly.

I flipped server managed configuration for m58 and m59 at the end of April and that caused this deadlock issue. If you manually set chrome://flags/#enable-midi-manager-dynamic-instantiation to Disabled at m58, you could escape from this issue. Also, until the end of April, m58 should have worked without this issue by default.

m59 can work if you manually set chrome://flags/#enable-midi-manager-dynamic-instantiation to Disabled. But you need to reset it to Default or Enabled when m60 comes. The flag won't make any difference after m61.

Sorry for inconvenience.