[BUG] Chromium causes continuous restart of my Behringer UMC204HD

[RJVB]

Describe the bug Running Chromium causes a continuous restart cycle of my Behringer UMC204HD audio interface

To Reproduce Steps to reproduce the behaviour:

1. Connect a Behringer U-Phoria UMCXXXhd device
2. Launch Chromium
3. The audio interface LEDs flicker because it's being restarted, also causing clicks in the (headphone) output.

Expected behaviour There is no reason for a webbrowser to access a sound device directly, certainly not when no site is opened and no content is being played.

Desktop (please complete the following information):

• OS: OS X 10.9.5
• Build 13F1911

Logs

Feb 25 23:03:14 Portia kernel[0]: USB Sound assertion in AppleUSBAudioEngine at line 1274
Feb 25 23:03:14 Portia kernel[0]: USB Sound assertion in AppleUSBAudioDevice at line 1500
Feb 25 23:03:14 Portia kernel[0]: USB Sound assertion in AppleUSBAudioDevice at line 634
Feb 25 23:03:14 Portia kernel[0]: USB Sound assertion in AppleUSBAudioDevice at line 286
Feb 25 23:03:15 Portia kernel[0]: USB Sound assertion in AppleUSBAudioEngine at line 1274
Feb 25 23:03:15 Portia kernel[0]: USB Sound assertion in AppleUSBAudioDevice at line 1500
Feb 25 23:03:15 Portia kernel[0]: USB Sound assertion in AppleUSBAudioDevice at line 634
Feb 25 23:03:15 Portia kernel[0]: USB Sound assertion in AppleUSBAudioDevice at line 286

(and on and on)

This same problem occurs with the last Google Chrome build to run on OS X 10.9.5 (v65.0.3325.181 from 2018). It does not happen with the Chromium core used in QtWebengine 5.8.0 .

[krackers]

Just to confirm that it's not an upstream bug, do you have another osx device running latest mainline Chromium you could test with?

Also fyi the last official Chrome build to run on OSX 10.9.5 is actually v68 (don't remember the exact build number off top of my head). This is newer than what google will officially serve you, you have to download it manually.

[RJVB]

Just to confirm that it's not an upstream bug, do you have another osx device running latest mainline Chromium you could test with?

I don't, no.

I'm quite certain it's not something specific to "Chromium-Legacy" but rather something in Chromium that doesn't react well to a return value from AppleUSBAudioDevice (possibly related to the assertions that get triggered in that library). I see those same warnings every time the audio interface is (re)initialised to some degree, including when I change the sampling frequency at which it's driven. But the actual reset with clicking only happens when I run Chrome/ium (plus when I plug in the device).

Testing with the latest mainline Chromium would require an up-to-date OS (which version, nowadays?), and that alone may cause the issue to disappear.

BTW, I tried making another audio device the default before starting the browser, and that didn't make a difference. Why would Chromium mess with an audio device it has no business with, and then keep trying the failed operation (because that's sure what it looks like)?

For me this disqualifies Chromium as a main browser...

[Wowfunhappy]

Why would Chromium mess with an audio device it has no business with

I don't know, but that part is kind of beside the point, since the underlying behavior almost certainly comes from upstream. We probably want to focus on why Chromium Legacy is causing it to restart continuously.

Anyway (as I said elsewhere), I wonder if this is related to the errors which are logged when Chromium Legacy is launched from the Terminal:

[43951:771:0212/183214.771492:ERROR:coreaudio_dispatch_override.cc(163)] Unable to resolve dyld_dynamic_interpose()
[43951:771:0212/183214.819587:ERROR:audio_manager_mac.cc(391)] Failed to get AudioUnit channel layout.: Error Domain=NSOSStatusErrorDomain Code=-10877 "The operation couldn’t be completed. (OSStatus error -10877.)" (-10877)

I've always assumed these were harmless, because maybe not?

[krackers]

Unable to resolve dyld_dynamic_interpose()

Well I can resolve that one, this thing (featuring my favorite-function-that's-sadly-unavailable-in-mavericks) was added in https://source.chromium.org/chromium/chromium/src/+/2f47f7f10b739f3dab4be68e972204a039e5ba82 to work around an osx bug related to sleep/wake audio.

At least the surface of Chrome that deals with CoreAudio is actually pretty minimal and self-contained, and there shouldn't be that many CoreAudio functions that mess with a device's state. Can you set breakpoint on CoreAudio's AudioOutputUnitStop and AudioUnitReset to see if anything turns up?

[RJVB]

work around an osx bug related to sleep/wake audio.

That only Chrome manages to trigger?

Can you set breakpoint on CoreAudio's AudioOutputUnitStop and AudioUnitReset to see if anything turns up?

Whom was this addressed to? If to me, is there a point I try doing that with the app installed by the prefpane?

[krackers]

@RJVB

That only Chrome manages to trigger?

I imagine not many apps register a persistent coreaudio callback? And even then the issue description is a bit unclear as to what exactly the symptoms are, but I'm fairly certain it's unrelated to the issue you're experiencing.

Whom was this addressed to?

Yes, was addressed to you; if you could set a breakpoint on those two CoreAudio methods and see if it gets called with the same period of speakers resetting, would be a good first step. If not, there are some other methods we can try.

I try doing that with the app installed by the prefpane?

Having prefpane installed or not won't matter, just use the same Chrome that you're seeing issues with.

[RJVB]

On Sunday February 26 2023 12:47:55 krackers wrote:

but I'm fairly certain it's unrelated to the issue you're experiencing.

Maybe, but the sleep/wake bit of audio devices does seem very relevant.

I try doing that with the app installed by the prefpane?

Having prefpane installed or not won't matter.

No, evidently not, the question was whether the binaries you provide have the appropriate information. I can check out the sources but I'm really not set up for building something as huge as modern Chromium.

[krackers]

I believe bluebox's builds have symbols present? I'm fairly certain that unlike prod chromium builds the stack traces posted all have symbols included. @Wowfunhappy can maybe confirm. But even if not, placing a breakpoint on AudioUnitReset etc. would be placing a breakpoint within CoreAudio library so whether or not the binary contains symbols shouldn't matter.

[Wowfunhappy]

I'm not sure if the standard builds have symbols...

@blueboxd Hey! I know you've produced debug builds a couple of times in the past, could we maybe get a new one?

[blueboxd]

Maybe I can upload a debug build for the current version within a few days, but all builds in this repo are already built with full symbols (symbol_level = 2 in args.gn). And debug builds can only provide line number info. (of course bit more traceable with no optimization though)

This same problem occurs with the last Google Chrome build to run on OS X 10.9.5 (v65.0.3325.181 from 2018)

At least, patches for -legacy and code for 10.13+ are not the cause. I guess OS/driver is responsible for this issue.

[RJVB]

At least, patches for -legacy and code for 10.13+ are not the cause. I guess OS/driver is responsible for this issue.

No, and probably ... and it'd be nice to have this "fixed" in -legacy because the browser is current not usable for me because of it.

[blueboxd]

Here's debug build and dSYM part 1, dSYM2 part 2 for r1111498.

@RJVB Could you investigate the trigger of assertions?

[RJVB]

@RJVB Could you investigate the trigger of assertions?

OK, will try. Give me a few days though.

Exactly what am I supposed to do with the dsym files?

[blueboxd]

With dSYM files and cloned sources, you can debug with source code. (On lldb, map /src/ to /path/to/cloned/src/ with lldb command settings set -- target.source-map /src/ /path/to/cloned/src/) Or, you can simply debug with any normal builds if you only need symbols.

First, please try setting breakpoints in main AudioUnit APIs or where Chromium calls AudioUnit (in //media/audio/mac?)

[RJVB]

With dSYM files and cloned sources, you can debug with source code.

I know, I meant it literally ... where do I put the files...

[krackers]

Can't you just place it anywhere and tell lldb to load a dsym for the current binary via add-dsym?

[RJVB]

Probably, but I'm used to getting them in all the places where normally I don't want them ;)

[krackers]

I'm used to getting them in all the places where normally I don't want them

I'm not sure I understand what you mean. Just loading the dsym shouldn't impact anything else on the filesystem?

But regardless, you shouldn't even need the source map or dsym to set breakpoint inside CoreAudio library itself.

[pjpreilly]

Yep... my streaming audio on Tuenin & Sirius craps out a few times a night... I let it play all night for noise while I'm sleeping... I just switched to Chrome on Linux & have no issues... probably related ...

[krackers]

Above issue is likely unrelated to this issue unless you too happen to use a "Behringer UMC204HD" or similar usb audio device.

[RJVB]

Can you set breakpoint on CoreAudio's AudioOutputUnitStop and AudioUnitReset to see if anything turns up?

Tried that, and nothing turned up. As in, the breakpoints didn't trigger...

Nothing relevant on the calling terminal either.

[krackers]

@RJVB What about AudioUnitSetProperty and AudioUnitGetProperty?

Also are you using bluebox's debug build? Those should have extra verbose logging, if you run with --enable-logging=stderr --v=1 (regular chrome builds have some logging statements optimized out).

[krackers]

Also breakpoint on AudioObjectGetPropertyData and AudioObjectSetPropertyData please

[krackers]

Also a few more: AudioDeviceStart, AudioDeviceStop, AudioOutputUnitStart, AudioDeviceGetProperty, AudioDeviceSetProperty

[RJVB]

Also are you using bluebox's debug build?

I tried to debug running that build but that proved a bit too much for my machine. I'll see what running it directly turns up, and try the other breakpoints too.

[RJVB]

None of these triggered (I just need to launch the browser without any particular page open to get the issue).

I noticed that the audio device actually disappears from the Option-Click drop-down menu under the volume icon in the menubar.

[krackers]

Did anything log to stderr/stdout when running debug build in verbose mode?

I wonder if you can just set a breakpoint on the entire coreaudio library. Don't know what the lldb syntax for that would be though.

[RJVB]

Did anything log to stderr/stdout when running debug build in verbose mode?

Not yet - how do you activate verbose mode (I tried --help but that isn't recognised)?

[krackers]

--enable-logging=stderr --v=1

[RJVB]

With verbose output and just the regular build I get this output:

[24860:1287:0317/030602.054251:VERBOSE1:device_event_log_impl.cc(220)]
[03:06:02.054] USB: EVENT: usb_device_handle_impl.cc:414 Failed to submit
transfer: No such device (it may have been disconnected)
[24860:1287:0317/030602.056397:VERBOSE1:device_event_log_impl.cc(220)]
[03:06:02.056] USB: USER: usb_service_impl.cc:388 USB device added:
vendor=5015 "", product=1288 "", serial="",
guid=517f1cf2-a04b-4a10-b2f7-a0fd45d271d8
[24864:14339:0317/030602.073951:VERBOSE1:network_delegate.cc(34)]
NetworkDelegate::NotifyBeforeURLRequest:
https://www.googleapis.com/affiliation/v1/affiliation:lookupByHashPrefix?key=AIzaSyBOti4mM-6x9WDnZIjIeyEU21OpBXqWBgw
[24880:29955:0317/030602.075133:VERBOSE1:script_context.cc(213)] Destroyed
context for extension
  extension id: nemmanchfojaehgkbgcfmdiidbopakpp
  effective extension id: nemmanchfojaehgkbgcfmdiidbopakpp
[24880:29955:0317/030602.075216:VERBOSE1:script_context.cc(213)] Destroyed
context for extension
  extension id:
  effective extension id:
[24860:1287:0317/030602.080912:VERBOSE1:device_event_log_impl.cc(220)]
[03:06:02.079] USB: USER: usb_service_impl.cc:402 USB device removed:
guid=517f1cf2-a04b-4a10-b2f7-a0fd45d271d8
[24860:1287:0317/030602.293319:WARNING:controller_impl.cc(1191)] Background
download complete, client: 6, completion type: 0, file size:45140
[24906:771:0317/030602.439562:VERBOSE1:statistics_recorder.cc(472)]
Collections of all histograms
Histogram: ChildProcess.FieldTrials.CreateFromShmemSuccess recorded 1
samples, mean = 1.0 (flags = 0x1)
0  O
  (0 = 0.0%)
1  -O
 (1 = 100.0%) {0.0%}
2  O
  (0 = 0.0%) {100.0%}

Histogram: HeapProfiling.InProcess.Enabled recorded 1 samples, mean = 0.0
(flags = 0x1)
0  -O
 (1 = 100.0%)
1  ...

Histogram: HeapProfiling.InProcess.Enabled.Utility recorded 1 samples, mean
= 0.0 (flags = 0x1)
0  -O
 (1 = 100.0%)
1  ...

Histogram: UMA.PersistentAllocator.UtilityMetrics.Errors recorded 0 samples
(flags = 0x41)

Histogram: UMA.PersistentAllocator.UtilityMetrics.UsedPct recorded 0
samples (flags = 0x41)
0 ...

Histogram: V8.Initializer.OpenV8File.Result recorded 1 samples, mean = 0.0
(flags = 0x1)
0  -O
 (1 = 100.0%)
1  ...

[24860:1287:0317/030603.442030:VERBOSE1:device_event_log_impl.cc(220)]
[03:06:03.441] USB: EVENT: usb_device_handle_impl.cc:414 Failed to submit
transfer: No such device (it may have been disconnected)
[24860:1287:0317/030603.442302:VERBOSE1:device_event_log_impl.cc(220)]
[03:06:03.442] USB: USER: usb_service_impl.cc:388 USB device added:
vendor=5015 "", product=1288 "", serial="",
guid=bbaff067-1c60-4ef7-a99e-74448091a1d8
[24860:1287:0317/030603.474655:VERBOSE1:device_event_log_impl.cc(220)]
[03:06:03.474] USB: USER: usb_service_impl.cc:402 USB device removed:
guid=bbaff067-1c60-4ef7-a99e-74448091a1d8
[24860:1287:0317/030605.042580:VERBOSE1:device_event_log_impl.cc(220)]
[03:06:05.042] USB: EVENT: usb_device_handle_impl.cc:414 Failed to submit
transfer: No such device (it may have been disconnected)
[24860:1287:0317/030605.042943:VERBOSE1:device_event_log_impl.cc(220)]
[03:06:05.042] USB: USER: usb_service_impl.cc:388 USB device added:
vendor=5015 "", product=1288 "", serial="",
guid=82995b84-cf20-40af-a7e7-fd14a1136692
[24860:1287:0317/030605.075949:VERBOSE1:device_event_log_impl.cc(220)]
[03:06:05.075] USB: USER: usb_service_impl.cc:402 USB device removed:
guid=82995b84-cf20-40af-a7e7-fd14a1136692
[24860:1287:0317/030606.371302:VERBOSE1:device_event_log_impl.cc(220)]
[03:06:06.371] USB: EVENT: usb_device_handle_impl.cc:414 Failed to submit
transfer: No such device (it may have been disconnected)
[24860:1287:0317/030606.371606:VERBOSE1:device_event_log_impl.cc(220)]
[03:06:06.371] USB: USER: usb_service_impl.cc:388 USB device added:
vendor=5015 "", product=1288 "", serial="",
guid=7e7d50b1-dd08-4275-926e-7a202d201a1d
[24860:1287:0317/030606.404522:VERBOSE1:device_event_log_impl.cc(220)]
[03:06:06.404] USB: USER: usb_service_impl.cc:402 USB device removed:
guid=7e7d50b1-dd08-4275-926e-7a202d201a1d
[24860:1287:0317/030607.712823:VERBOSE1:device_event_log_impl.cc(220)]
[03:06:07.712] USB: EVENT: usb_device_handle_impl.cc:414 Failed to submit
transfer: No such device (it may have been disconnected)
[24860:1287:0317/030607.713116:VERBOSE1:device_event_log_impl.cc(220)]
[03:06:07.713] USB: USER: usb_service_impl.cc:388 USB device added:
vendor=5015 "", product=1288 "", serial="",
guid=5840670b-1489-4381-8632-de531084e695
[24860:1287:0317/030607.745291:VERBOSE1:device_event_log_impl.cc(220)]
[03:06:07.745] USB: USER: usb_service_impl.cc:402 USB device removed:
guid=5840670b-1489-4381-8632-de531084e695

[krackers]

and just the regular build

Regular build doesn't include all the logging statements, did debug build not run? The log does confirm that the device keeps getting reinitialized though.

[krackers]

Also interesting, apparently source for AppleUSBAudio kext is actually open sourced: https://github.com/nickdowell/AppleUSBAudio-273.4.1/blob/master/AppleUSBAudioDevice.cpp

[RJVB]

But that code is over 12 years old. It might even be older than the version I have on my system...

But yeah, if that can be corrected, embedded and override the system version it could solve problems

[RJVB]

Here's the output from the debug build. I started it with the UMC not connected, waited for all spewing to stop, plugged in the UMC for a while and disconnected it again:

[27687:771:0317/221344.121656:VERBOSE1:scheduled_action.cc(148)] ScheduledAction::execute 0x107001e5ae8: have function
[27665:771:0317/221347.755583:VERBOSE1:device_event_log_impl.cc(224)] [22:13:47.754] USB: EVENT: usb_device_handle_impl.cc:413 Failed to submit transfer: No such device (it may have been disconnected)
[27665:771:0317/221347.758933:VERBOSE1:device_event_log_impl.cc(224)] [22:13:47.758] USB: USER: usb_service_impl.cc:388 USB device added: vendor=5015 "", product=1288 "", serial="", guid=9ad9539c-96b1-4b4e-bf74-de9d63cee21a
[27665:771:0317/221347.786122:VERBOSE1:device_event_log_impl.cc(224)] [22:13:47.786] USB: USER: usb_service_impl.cc:402 USB device removed: guid=9ad9539c-96b1-4b4e-bf74-de9d63cee21a
[27665:771:0317/221349.568348:VERBOSE1:device_event_log_impl.cc(224)] [22:13:49.567] USB: EVENT: usb_device_handle_impl.cc:413 Failed to submit transfer: No such device (it may have been disconnected)
[27665:771:0317/221349.571584:VERBOSE1:device_event_log_impl.cc(224)] [22:13:49.571] USB: USER: usb_service_impl.cc:388 USB device added: vendor=5015 "", product=1288 "", serial="", guid=394dbd46-72af-4690-9c7d-53731e39e7dd
[27665:771:0317/221349.600529:VERBOSE1:device_event_log_impl.cc(224)] [22:13:49.600] USB: USER: usb_service_impl.cc:402 USB device removed: guid=394dbd46-72af-4690-9c7d-53731e39e7dd
[27665:771:0317/221351.373984:VERBOSE1:device_event_log_impl.cc(224)] [22:13:51.373] USB: EVENT: usb_device_handle_impl.cc:413 Failed to submit transfer: No such device (it may have been disconnected)
[27665:771:0317/221351.377527:VERBOSE1:device_event_log_impl.cc(224)] [22:13:51.377] USB: USER: usb_service_impl.cc:388 USB device added: vendor=5015 "", product=1288 "", serial="", guid=b56337ea-019f-4df9-8d1b-0b59fd5970a9
[27665:771:0317/221351.404944:VERBOSE1:device_event_log_impl.cc(224)] [22:13:51.404] USB: USER: usb_service_impl.cc:402 USB device removed: guid=b56337ea-019f-4df9-8d1b-0b59fd5970a9
[27665:771:0317/221353.196411:VERBOSE1:device_event_log_impl.cc(224)] [22:13:53.195] USB: EVENT: usb_device_handle_impl.cc:413 Failed to submit transfer: No such device (it may have been disconnected)
[27665:771:0317/221353.200043:VERBOSE1:device_event_log_impl.cc(224)] [22:13:53.199] USB: USER: usb_service_impl.cc:388 USB device added: vendor=5015 "", product=1288 "", serial="", guid=d20db477-92ab-4963-9863-cbe275183e6b
[27665:771:0317/221353.227828:VERBOSE1:device_event_log_impl.cc(224)] [22:13:53.227] USB: USER: usb_service_impl.cc:402 USB device removed: guid=d20db477-92ab-4963-9863-cbe275183e6b
[27665:771:0317/221355.011741:VERBOSE1:device_event_log_impl.cc(224)] [22:13:55.011] USB: EVENT: usb_device_handle_impl.cc:413 Failed to submit transfer: No such device (it may have been disconnected)
[27665:771:0317/221355.015209:VERBOSE1:device_event_log_impl.cc(224)] [22:13:55.015] USB: USER: usb_service_impl.cc:388 USB device added: vendor=5015 "", product=1288 "", serial="", guid=36dcdf3c-71da-4ffb-8604-0d7ed33a54a4
[27665:771:0317/221355.041683:VERBOSE1:device_event_log_impl.cc(224)] [22:13:55.041] USB: USER: usb_service_impl.cc:402 USB device removed: guid=36dcdf3c-71da-4ffb-8604-0d7ed33a54a4
[27665:771:0317/221356.826004:VERBOSE1:device_event_log_impl.cc(224)] [22:13:56.825] USB: EVENT: usb_device_handle_impl.cc:413 Failed to submit transfer: No such device (it may have been disconnected)
[27665:771:0317/221356.829296:VERBOSE1:device_event_log_impl.cc(224)] [22:13:56.829] USB: USER: usb_service_impl.cc:388 USB device added: vendor=5015 "", product=1288 "", serial="", guid=641cc924-3d90-4eec-9d9e-b7e24eac42f1
[27665:771:0317/221356.857347:VERBOSE1:device_event_log_impl.cc(224)] [22:13:56.857] USB: USER: usb_service_impl.cc:402 USB device removed: guid=641cc924-3d90-4eec-9d9e-b7e24eac42f1
[27665:771:0317/221358.626309:VERBOSE1:device_event_log_impl.cc(224)] [22:13:58.625] USB: EVENT: usb_device_handle_impl.cc:413 Failed to submit transfer: No such device (it may have been disconnected)
[27665:771:0317/221358.629597:VERBOSE1:device_event_log_impl.cc(224)] [22:13:58.629] USB: USER: usb_service_impl.cc:388 USB device added: vendor=5015 "", product=1288 "", serial="", guid=7ef63b2f-b8af-4784-a0b5-e72f7b4618f6
[27665:771:0317/221358.658215:VERBOSE1:device_event_log_impl.cc(224)] [22:13:58.658] USB: USER: usb_service_impl.cc:402 USB device removed: guid=7ef63b2f-b8af-4784-a0b5-e72f7b4618f6
[27665:771:0317/221400.427566:VERBOSE1:device_event_log_impl.cc(224)] [22:14:00.426] USB: EVENT: usb_device_handle_impl.cc:413 Failed to submit transfer: No such device (it may have been disconnected)
[27665:771:0317/221400.431059:VERBOSE1:device_event_log_impl.cc(224)] [22:14:00.430] USB: USER: usb_service_impl.cc:388 USB device added: vendor=5015 "", product=1288 "", serial="", guid=c3a0ed6c-07d7-44ba-bdd4-dc422cec6f53
[27665:771:0317/221400.458646:VERBOSE1:device_event_log_impl.cc(224)] [22:14:00.458] USB: USER: usb_service_impl.cc:402 USB device removed: guid=c3a0ed6c-07d7-44ba-bdd4-dc422cec6f53
[27665:771:0317/221401.321201:VERBOSE1:service_worker_version.cc(2352)] ServiceWorker startup timed out. The worker was in startup phase: Script evaluation.
[27665:771:0317/221401.321651:ERROR:service_worker_task_queue.cc(233)] DidStartWorkerFail nemmanchfojaehgkbgcfmdiidbopakpp: 14
[27668:16387:0317/221402.084442:VERBOSE1:network_delegate.cc(35)] NetworkDelegate::NotifyBeforeURLRequest: https://update.google[27665:771:0317/221404.072583:VERBOSE1:device_event_log_impl.cc(224)] [22:14:04.072] USB: EVENT: usb_device_handle_impl.cc:413 Failed to submit transfer: No such device (it may have been disconnected)
apis.com/service/update2/json?cup2key=13:pSa9NLMpNJmyu6_D1p2dPlcQZjvc3Ul3si73LqW0UcU&cup2hreq=fb9dffed6bd31b1dba738e27d77d13182b3147b7224a0bdae3608c4427d6d853
[27668:16387:0317/221423.584197:VERBOSE1:spdy_session_key.cc(45)] SpdySessionKey(host=update.googleapis.com:443, proxy=direct://, privacy=1
[27668:16387:0317/221423.601763:VERBOSE1:spdy_session_key.cc(45)] SpdySessionKey(host=update.googleapis.com:443, proxy=direct://, privacy=1

[krackers]

Not much more information than the non-debug build. Whatever Chrome is doing, it's not only affecting the audio interface though, it's causing a reinitialization of the device entirely, which is consistent with what you observed of the device disappearing.

How about just setting a breakpoint inside all functions in CoreAudio, AudioToolbox, and AudioUnit. Something like https://stackoverflow.com/questions/44928511/gdb-lldb-break-at-all-functions-of-specified-module-shared-library should work, although I don't how exactly you'd specify a framework in there, and depending on how many functions there are, it could possibly not work well. Could probably use image lookup inside lldb to get the right name.

[krackers]

Another idea: Could this be somehow related to webusb? Maybe Chrome is trying to get more information about the connected device and the way it's doing so is causing a reset somehow. I don't know if there's a way to even disable webusb though

[Wowfunhappy]

I don't know if there's a way to even disable webusb though

I think launching Chromium with the command line flag --disable-features=WebUSB will do it.

When WebUSB was temporarily disabled in Chromium due to security issues, users were told to use the opposite command line flag to manually re-enable the feature. https://bugs.chromium.org/p/chromium/issues/detail?id=819197

[krackers]

Nice find Wowfunhappy, but it's not clear if that flag is still valid or not. You could try going to chrome://usb-internals

For tracing, seems like the webusb -> darwin code is within the files: https://source.chromium.org/chromium/chromium/src/+/main:services/device/usb/usb_service_mac.cc?q=iokit&ss=chromium%2Fchromium%2Fsrc:services%2Fdevice%2Fusb%2F

https://source.chromium.org/chromium/chromium/src/+/main:services/device/usb/usb_device_mac.cc?q=iokit&ss=chromium%2Fchromium%2Fsrc:services%2Fdevice%2Fusb%2F

https://source.chromium.org/chromium/chromium/src/+/main:services/device/usb/usb_device_handle_mac.cc?q=iokit&ss=chromium%2Fchromium%2Fsrc:services%2Fdevice%2Fusb%2F

(They also use libusb which has its own OS shims, so I'm not 100% sure).

I guess maybe you'd try tracing all functions in https://developer.apple.com/documentation/iokit/iousbdeviceinterface187

[krackers]

Seems to still be a valid option:

https://source.chromium.org/chromium/chromium/src/+/main:out/webview-Debug/gen/third_party/blink/renderer/platform/runtime_enabled_features.cc;l=2726?q=%22%5C%22WebUSB%5C%22%22&ss=chromium%2Fchromium%2Fsrc

While you're at it maybe disable WebHID too.

[RJVB]

Thanks, that seems like two very relevant things to try. I don't even see why I would want this functionality activated on a real, pardon, desktop computer (on a Chromebook you probably can't get around it for many things).

I'd planned to see if there were no hidden flags ("experiments") that have to do with USB, but with this symptom my reflex is always to quite Chrome as soon as possible.

BTW, I always use FUS to go to the login screen before suspending the computer and it's happened 2 times now that it takes a good minute to get the login dialog after having run the Chromium debug build. Last time it took a reboot to fix this. Going to have to figure out a way to get at least an idea of what's holding up the process!

[Wowfunhappy]

Thanks, that seems like two very relevant things to try. I don't even see why I would want this functionality activated on a real, pardon, desktop computer (on a Chromebook you probably can't get around it for many things).

For what it's worth, it's also useful if you are on an operating system that's too old to be supported by most modern software, but can run Chromium Legacy.

As a somewhat random example, I used a website + WebUSB to jailbreak a Nintendo Switch. I'm sure I could have downloaded the source of fusee-gelee and compiled it myself for 10.9, but WebUSB saved me a few hours.

[RJVB]

Indeed, that's really something I'd want to do every day ;)

This does make me realise something: did you ever think of making a similar build of Electron, the engine used by so many applications nowadays?

Interestingly I've built an older version of Ferdi against about the latest Electron version that builds on 10.9 "out of the box". It must thus be equivalent to the latest Google Chrome version I also have installed. The latter shows the USB issue as reported before, but I run Ferdi without any problems.

[Wowfunhappy]

This does make me realise something: did you ever think of making a similar build of Electron, the engine used by so many applications nowadays?

I've definitely thought about it! I have not had the energy to actually try it. I do suspect you could apply the Chromium Legacy patches to get it working!

I do frequently use the built-in option to install websites as "apps": more tools → Create Shortcut → Open as Window. It's basically the same thing as Electron, except more memory efficient anyway. It works great with Slack for example!

[RJVB]

Why more memory efficient? Assuming you already have the browser running and don't get the additional overhead?

I use Ferdi (or Ferdium) for web-based messenger services, a bunch of forums and a handful of sites that work better in Chrome than Firefox. It does give me overhead, but with its hibernation feature and the fact that it releases many resources including the CPU when you close the window it's actually leaner than having the same services in browser tabs. Plus, I can quit this "work set" more easily than quitting my entire browser.

[Wowfunhappy]

Why more memory efficient? Assuming you already have the browser running and don't get the additional overhead?

As I understand it, Electron apps can't share memory because they're all running different versions of the Chromium engine. Of course, if you aren't also browsing the web in Chromium, or you only run one Electron app at a time, this won't matter.

With the Chromium-installed "web apps", it's just like having another browser tab open.

[RJVB]

Well, good news: disabling just WebUSB support "solves" the issue, and there is indeed a flag that does so too: the single WebUSB related enable-webusb-device-detection, which even says to disable it in case problems are observed with USB devices. So I don't have to bother figuring out how to inject the disable-features flag into the argument list!

We'll have to see how stable this is in practice, because the effect of --disable-features=WebUSB is cancelled when you open chrome://usb-internals.

So, thanks!

[krackers]

Awesome!

out how to inject the disable-features flag into the argument list!

You can do this by replacing the chromium executable with a dummy shell script that calls the real binary with the args set. Or if you launch via terminal, open -a allows you to set args.

don't even see why I would want this functionality activated on a

I agree, I think surface of modern web browser has gotten too bloated, and having these features only encourages people to write web apps instead of native. origin private file system is the latest abomination. I think one of the main use-cases of this was just that so they could run SQLite compiled down to webassembly, writing rows to a sqlite db that now gets encapsulated in an opaque blob. What madness (especially since there was a perfectly good WebSQL that was killed). Did you know there's even apparently WebSerial for access to serial ports? At this point the browser has become an abstraction layer over the OS, which could be useful, if it was kept separate from "browser as a place to view hypertext documents".

[RJVB]

You can do this by replacing the chromium executable with a dummy shell script that calls the real binary with the args set

Trust me, I know :) In fact the Chromium BundleExec is already a shell script. However, changing that script requires re-signing the whole bundle. I might try doing that anyway btw, because right now I get a systematic keychain dialog if I really want to give Chromium access to the entry with the Google sync credentials...

At this point the browser has become an abstraction layer over the OS, which could be useful, if it was kept separate from "browser as a place to view hypertext documents".

Amen to that! I've been saying that for years w.r.t. using QtWebengine as a replacement for QtWebkit. But ... serial ports, rs232?!

[Wowfunhappy]

Trust me, I know :) In fact the Chromium BundleExec is already a shell script. However, changing that script requires re-signing the whole bundle.

This is something my PrefPane does in order to set defaults and add other launch arguments, it's not done in vanilla Chromium Legacy. And atm my PrefPane doesn't do any re-signing (I may change that at some point), so feel free to edit the shell script to add --disable-features=WebUSB. (You may want to make the change to the "master" shell script inside the PrefPane so it isn't lost every update.)

[RJVB]

Right. Well, I guess that could explain the keychain access nagging!