Shell Extension Blocking Idea For UWP / Appx Version Changes

Help & Support
1

I really like being able to block shell extensions. For me the Dropbox one especially slows down the context menu, so it's a godsend for that.

The only minor inconvenience I've noticed is that I whenever an Appx app updates, the path / full name of the app changes to include the version. I guess this results in the new extension version getting a unique id behind the scenes, and means it needs to be re-blocked each time Dropbox updates (or whatever other app). This seems to only be a problem with Appx / UWP type extensions only.

You can see how often Dropbox updates and the new version always is unblocked until I notice it's back. Other apps are like that too, though less frequent.

image
image1296×697 65.4 KB

Idea: Have a block on a UWP app's extension auto apply to any version of the app, or just inherit the previous version if it detects that the old one isn't available anymore.

It seems that Opus is already able to distinguish the active vs uninstalled versions, even if indirectly, because it shows the full name including version of the old ones, but not the latest one. I assume it stores the full app/extension identifier behind the scenes to use when drawing the context menu, and just displays the app part of the name in the settings menu if it can find it.

I imagine there are several ways this could be implemented and at different stages. Like depending on what information is available when the context menu starts to draw (such as whether it is identified via a GUID or if it includes the app's name or something). I imagine that would determine when the blocklist-updating logic would have to take place, or if it wouldn't need to occur at all and a more app-scoped rule could be applied directly without any extra overhead.

1 Like
2

You can use * wildcards in the identifier to avoid tying it to a particular version. E.g. Have a look at the default block for AppleInc.iCloud*

3

Ah I never noticed the "Add Item to Block List" menu option before. I'm having trouble getting it to keep the wildcard though.

If I add it like this it detects it:

image
image681×457 11.8 KB

Though after hitting OK it doesn't seem to have an effect, the current Dropbox item stays there. I can get it to show up if I remove the current Dropbox item via Right Click "Remove", then it shows up with the asterisk:

image
image987×234 14.5 KB

However after hitting apply and OK, then re-opening the menu, the one with the wildcard has disappeared. It just shows the previous entry like before:

image
image1372×243 16.7 KB

4

Confirmed, it looks like those wildcard blocks can't be added manually at the moment, only by us (as far as I can tell).

Making it so you can add them as well would be good, for sure.

1 Like
6

This seems to work as expected here, can you please confirm if you see something different?

  1. Dropbox not blocked by default

image
image718×273 13.8 KB

  1. Add wildcard block entry manually

image
image693×461 16.2 KB

  1. Dropbox now shows as blocked

image
image435×149 2.71 KB

  1. Click OK and exit Opus, then restart. Dropbox still shows as blocked

image
image489×156 3.17 KB

  1. Confirm Dropbox menus not shown in context menu

image
image424×1068 24.7 KB

7

Well the problem isn't that the extension isn't blocked after doing that - it is, the problem I was getting at in the original post was that when Dropbox next updates it won't be blocked anymore.

8

I can't see why it wouldn't be. If you look in the configuration file you can see the entry is recorded as a wildcard, not for a specific version.

9

Ah you're right the exported xml block list does have the asterisk in there.

For some reason I thought I had tried exporting the list after adding the asterisk and didn't see it, but I must've been mistaken.

I'll take note of the current dropbox version and see if it is still blocked when the next version comes around. But seems like it should.

Edit: Yep it works :+1: