How does an app bind a custom display name to a sidebar Favorites entry pointing at a NSFileProviderDomain mount, while preserving the FP extension's icon? Inserting the volume URL directly via LSSharedFileListInsertItemURL keeps the icon but uses the volume's default name. Inserting an alias-bookmark file or symlink to the volume with a custom filename gives the custom name but drops the icon to the generic alias glyph. Since other apps seem to have achieved this, I wonder what's missing in order to get it working. I've dropped a lot of work into this already and tried so many things but none has been working. What's complicating things is that working with plugins are easy to get wrong – the old plugin might not be correctly unloaded so you get stale behaviour etc. I've already spent more time with this than I'd care to admit. Since LSSharedFileListInsertItemURL is deprecated it's natural that setting the name/icon is getting ignored, but there's clearly a way to make it work. For apps that have this working I did the following test: Change the name - icon stays the same Restart Finder - icon now becomes a generic icon Change the name back to the original Restart Finder - icon reverts to the "proper" icon. Apart from this I've been able to verify that aliases produced by my app has the same data as apps with this working. Any hints would be greatly appreciated.

I am developing a FileProvider extension which will be launched for one or more domains. In the case where I have two domains, say with displayNames "Foo" and "Bar", the finder will then show "MyExtension - Foo" and "MyExtension - Bar" respectively after registering them with addDomain. However, if I only have a single domain, let's say "Foo" – then I just see "MyExtension" rather than "MyExtension - Foo". Now ideally I'd like to be able to control the entire name, but barring that at least be able to show the displayName even with a single domain. How can I achieve that?

I am writing a midi polyfill, to bridge Core Midi with Safari. This, in itself, is not a problem. The problem is that the Web Extension will get suspended the moment it's no longer actively called. This means that no callbacks due to midi changes from core midi can be passed back to the web page. If I use a setInterval call in background.js, then this keeps the extension alive somewhat, but the setInterval self ping will get aborted eventually, making the Extension suspend itself. I know of a fairly contrived workaround using the container application over XPC, but I am hoping there is a way to keep the Web Extension alive - or at least keep a thread in the same process as the Web Extension alive. Or any such workaround. Setting background to "persistent": true does not seem to make any difference.