When I asked this before, the answer was "by design".
Only selected important permissions are listed up in the top page, and others can be found under the all sites menu in a per-site manner.

You could find https://permission.site there, and select to see MIDI permission and the UI to reset it.

https://support.google.com/chrome/answer/114662
Here is an online manual for the Android site settings, but this does not look up to date?

+finnur to whom I asked this question one year ago.

Here is a short answer in the thread, just in case.

> Android hardly had a site settings UI at all before I was drafted into that work and the only way to access the midi permission then was to go through the All Sites list. That remains the main way to access it today.
>
>It is true that we didn't think midi warranted a separate category under site settings, but technically that was also the case before.
>
>I do believe that not having a top level category for midi was intentional -- there are a few permissions that are not as critical that also don't get their own category.

I was part of these discussions and I let myself be convinced that less frequently used permissions don't need their own category, but I'm not so sure now.

1. If I come to the settings UI with no particular goal, I just want to get an overview which permissions Chrome supports, then I want to see all of them.

2. If I come to the settings UI looking for a particular permission type X, then obviously I prefer X to be in the list. And if this is to hold for every X, then all permissions must be in the list.

3. If I come to the settings UI looking for a particular site, then I click "All sites" which is right on the top, and the number of permission types below doesn't really matter.

I'm not sure if there is any value in making the list shorter if it already scrolls at small mobile screens anyway.

I can imagine an argument that some categories are mostly unused and can be hidden while empty, but this bug reports them being hidden even when nonempty, so that's not the case.

FYI, one my feedback to use "All sites" is that it takes so long time to show the site list, e.g. on my daily used Android Chrome on Nexus 5X, it keeps silent for tens seconds until it shows something. But it works somehow and would be ok for such rare use.

Also the text of "All sites" is just confusing. If it says "All permissions" I can guess it may contain other permissions. Also, listing permission items and the "All sites" together in the same UI group look inconsistent. Because others are "per type" but "All sites" is "per site".

Anyway, let me remove WebMIDI label now since this is a topic for site settings UX, and would be better to be discussed by UX experts.

All Sites taking too long is a separate issue (already been filed).

But for the rest: Yeah, we've had this discussion before and it is still working as intended. A top-level category is very useful for highly sensitive categories, like Location because if people are worried about privacy implications they can get a good overview of all sites that have that particular permission (and others) and configure accordingly. This isn't really the case for MIDI. I don't think anyone would get worried about MIDI in the same way and need an overview of all sites that have MIDI.

Adding a top-level category involves engineering work and adds to both the cognitive overload for the user and the code complexity for devs. I don't see MIDI warranting that; I'm actually surprised to see it implemented on desktop -- I wonder if it even got approval from UX.

As for the other categories listed that are supposedly missing: They seem mostly not applicable to mobile (For example: Images: Intentionally left out because Android uses the Data Saver feature instead. Zoom level: that one is not saved on mobile, I believe. Handlers: I'm sure Android has its own way of doing protocols, if it does it at all).