MediaArea
Windows 11 integration need an option for keeping the old context menu
Feedback from a user. When calling the context menu from Total Commander, there is no more the context menu because the Windows 11 Explorer style is not supported, so we need an option for keeping the old context menu as it is done in other tools.
WinRAR:
TreeSize:
Unable to reproduce. Windows 11 shell extensions work fine in Total Commander including properly opening the file in MediaInfo and Mp3tag. The entries for Clipchamp, MediaInfo, Quick Share, Mp3tag and Notepad are all Windows 11 new-type shell extensions.
In my opinion the user should contact developer of Total Commander for any compatibility issues instead of requesting changes from each and every app to be compatible with Total Commander. Most apps that implement the new shell extension no longer have the legacy shell extension.
Unrelated note: Many apps do not even have an option to disable the context menu entry. Mp3tag only has option to disable in Store version while the installer version can only enable/disable the context menu during installation.
If it works properly in Windows File Explorer but not on Total Commander then I have no idea why. It works when I tested in Total Commander. Only the developer of Total Commander will know.
In Explorer the same thing. In main context menu - available on files and folders. Shift+context menu - only on folders.
If it works properly in Windows File Explorer but not on Total Commander then I have no idea why.
Windows File explorer uses the new package but Total Commandes uses the old fashion registry, so it makes sense up to...
It works when I tested in Total Commander.
This part is weird, it does not work on 1 machine but works on another machine... If Total Commander does not use the new package, how does it get the context menu on @cjee21 machine? Maybe something remaining from a dev? Does it disappear if options are unchecked in MediaInfo preferences?
In Explorer the same thing. In main context menu - available on files and folders. Shift+context menu - only on folders.
MediaInfo only creates one entry. Since it appears in the main context menu means it is working properly. The entry in shift+context menu should contain everything that the main context menu has. If it does not then it may be a Windows bug but I have not seen this happen before.
Maybe something remaining from a dev? Does it disappear if options are unchecked in MediaInfo preferences?
If this refers to my test, I have done the test on a newly set-up fresh-install Windows 11 VM (official ISO direct from microsoft.com) with nothing else installed other than the test apps because I do not want to install shareware/trialware on my main PC so there is no possibility of anything remaining from development or previous installs etc.
So I dug abit and found this by author of Total Commander:
Total Commander does not create the context menu by itself. It requests it from Windows via the IContextMenu interface, and then adds its own entries. So when context menu entries are missing, then the program which owns these entries is responsible when they are missing in third party programs. Total Commander cannot control that.
MediaInfo's shell extension does not have any features that prevents it from being used/loaded by third party programs. The fact that it appears when a folder is selected in https://github.com/MediaArea/MediaInfo/issues/994#issuecomment-2541700900 is evidence for this.
Piecing this together with https://github.com/MediaArea/MediaInfo/issues/994#issuecomment-2541738716:
In Explorer the same thing. In main context menu - available on files and folders. Shift+context menu - only on folders.
It now makes sense. This issue is not about old/legacy vs new/packaged shell extensions. It is also not about shell extension not working in Total Commander or third party apps. It is that MediaInfo's entry is missing from legacy context menu when a file is selected but not when folder is selected.
Since https://github.com/MediaArea/MediaInfo/issues/994#issuecomment-2541738716 mentions that it is available for files and folders in the main/new context menu, I have no idea why it does not appear in the other. The fact that it appears on the main context menu means Windows has correctly picked up the registration and successfully loaded the shell extension. It also means MediaInfo's shell extension has correctly read the Preferences and enabled itself. In addition, it works on other Windows 11 systems including in Total Commander for both files and folders. It is looking likely that this is an issue with the particular Windows installation and is not something that MediaInfo can solve.
Feedback from a user. When calling the context menu from Total Commander, there is no more the context menu because the Windows 11 Explorer style is not supported,
This line in the initial post is now proven to be false by screenshots in https://github.com/MediaArea/MediaInfo/issues/994#issuecomment-2541343905 and https://github.com/MediaArea/MediaInfo/issues/994#issuecomment-2541700900.
Note: It is actually not 'Windows 11 style' as it is supported since Windows 10 Build 19000 (4 years ago) and is the only method that can be used by Store apps.
It now makes sense. This issue is not about old/legacy vs new/packaged shell extensions. It is also not about shell extension not working in Total Commander or third party apps. It is that MediaInfo's entry is missing from legacy context menu when a file is selected but not when folder is selected.
I am completely lost. Fact is that I receive feedback because something has changed, but the exact issue seems different depending on the machine.
Let's try to summarize, on specific machines:
- Before the switch to packaged, there was a menu in e.g. Total Commander
- After the switch to package, this menu is no more there, regression It means that at least one thing was not well "converted" from legacy to packaged, what? I don't know.
Additionally, I just received this email:
since MediaInfo 24.12 the context menue entries from MediaInfo are missing on Windows 11 x64 though the settings are set to enable them. I guess you removed the classic context menue entries and only install the "new" M$-Store-forced context menue... This is a bad solution as I set windows to use classical context menues and do really not want to do 2 more clicks to get my context menue and the M$-entries are almost the least interesting ones for me...
Would you mind reimplementing classical context menue entries or could you @ least provide a regfile to reenable the classical context menu entries..?
It seems that we have an option somewhere for the classic context menu on Win11... For the moment the easiest solution I see is to keep the legacy menu in addition to the packaged menu, maybe without option so easier, if I understand correctly it would not create duplicate entries because it is not at the same place, so does it hurt? If duplicate entry, we add an option for people having uncommon configs...
is not something that MediaInfo can solve.
Something was working in the past and is not working anymore, so we can solve that at least by reverting to the previous code, but we could also find a way to have everyone happy. changing something is not easy, different configs, different people, different usages. Now you know why I am reluctant to change something ;-).
Windows will automatically populate both new and old context menus when a context menu entry that is registered by a package is present.
This means @sevastopolcat that has entries for new menu but not the old one and only for files but not folders is an issue unrelated to MediaInfo but is something going wrong in Windows. In this case it is expected that it does not work in Total Commander too since this app uses Windows API to build the old style menu.
It also means doing "For the moment the easiest solution I see is to keep the legacy menu in addition to the packaged menu" will cause duplicate entries.
For "This is a bad solution as I set windows to use classical context menus", something else is the issue as well. I just tried setting Windows to only use the old menu and MediaInfo is still present there.
So in conclusion, all the issues so far are not directly due to the new shell extension.
In addition, right now, MediaInfo will only remove the old shell extension when the new one is found in the registry. @JeromeMartinez can try removing this if statement and the old one would not be disabled. https://github.com/MediaArea/MediaInfo/blob/886b55528a23523ecd2a3270612bf64816738b2b/Source/Common/Preferences.cpp#L827
If anyone still has the wrong idea about Windows 11 context menus, This new shell extension method is supported on Windows 10 Build 19000 onwards. Although this method is required to appear in new Windows 11 context menu, it has nothing to do with Windows 11 or the new context menu. This new shell extension does not only work on the new context menu but works on existing/legacy context menus since Windows 10 Build 19000.
So it is not about replacing old shell extension with new one equals will not work if new context menu is disabled or third party app does not support new context menu. Replacing old with new should have no difference other than ability to open multiple files in the same MediaInfo instance. If it breaks something, then there is an issue somewhere and putting back the old shell extension would be just a workaround and not a solution to the underlying issue.
we could also find a way to have everyone happy
My idea (one of the following):
- only implement the package identity stuff on Store version of MediaInfo (guarantees no issues with users of exe installer as it will be exact same as before but without Windows 11 integration)
- add option in installer to opt-out of package identity (users who mess with their Windows such as disabling services that are not meant to be disabled will still encounter issues due to embedded manifest in MediaInfo.exe)
After some more digging, turns out this issue (entry not appearing in legacy menu on certain PCs and in some cases only affects files and not folders; third party apps also will be missing the entry in this case) has been encountered by other apps before. It appears to be a strange Windows bug that can be mitigated like the following: https://github.com/M2Team/NanaZip/blob/e54855e1cfbc775f586a08a6298248b52559e2f8/NanaZipPackage/Package.appxmanifest#L276-L277
Comparing the IDs of a few apps, I see no pattern in what causes it to not work on certain PCs. It is not known what factors on a PC triggers the issue too.
It appears to be a strange Windows bug that can be mitigated like the following
I am fine with changing that if it is a way to mitigate the issue...
only implement the package identity stuff on Store version of MediaInfo
The feature is good for most users, limiting that to the Store would be sad, it is not because there are a couple of issues that we need to wipe out the feature for most users.
add option in installer to opt-out of package identity
I don't get why we can not just add an option for switching back to the registry and the package just leave like if the option is disabled in that case, no need to remove everything, or do I miss something?
- Menu option unchecked (classic menu option grayed out) = no registry,
WindowsShellExtensionleaves - Menu option checked + classic menu option unchecked = no registry,
WindowsShellExtensionhandles it - Menu option checked + classic menu option checked = registry,
WindowsShellExtensionleaves
PS: another case at https://sourceforge.net/p/mediainfo/discussion/297610/thread/364aa79842/
I don't get why we can not just add an option for switching back to the registry and the package just leave like if the option is disabled in that case, no need to remove everything, or do I miss something
After we workaround the Windows bugs, most of the other issues (such as MediaInfo not launching) will likely only be mitigated by complete removal of package identity. Those issues will likely be caused by corrupt Windows or disabling of core Windows services. Even this current bug is caused by packaging and likely before the shell extension is loaded and decides whether to show.
Therefore I do not see much benefit of having an option in Preferences for that. It will add the following:
- More code in MediaInfo GUI
- Another string to translate to so many languages
- Changes to Preferences window which may break things again (like that day) especially if I do it on C++Builder 12 (no idea why only Preferences breaks and not Main)
- Possibility of users asking about what the new option does, what's the difference between the two extensions etc.
- Having to maintain legacy shell extension even after dropping support for Windows 10 < Build 19000 in the far future
Temporarily (before reinstalling Windows), I bypassed my problem not entirely correct. Installed the installer 24.11.1 and rolled on top of the portable 24.12. Once the same problem was with Mp3tag. After the next updates of the OS and the program itself, it quietly disappeared.
Once the same problem was with Mp3tag. After the next updates of the OS and the program itself, it quietly disappeared.
So it can happen to Mp3tag too... Mp3tag Verb Id is Mp3tagShell so starts with M too.
Microsoft Notepad Verb Id is OpenInNotepad and does not seem to have issues? According to NanaZip devs, using OpenTerminalHere1 causes issues too. NanaZipShellExtension also issue but CNanaZipShellExtension or CNanaZip no issues. I see no pattern.
Fun fact: Microsoft registered Notepad shell extension for Directory as well but of course it does not show.
Temporarily (before reinstalling Windows)
@sevastopolcat if you plan to reinstall Windows, you can wait for a new build (#997) with renamed Verb Id first to see if it can bypass the issue.
...you can wait for a new build...
Of course, I will wait for the new version(s) and inform the results.
@cjee21 I received this use case of a user not finding anymore MediaInfo in the context menu:
I use a tool called "Winaero Tweaker" ( https://winaero.com/winaero-tweaker/ ) Luckily this tool explains what it does for (nearly) every tweak it contains and so their explanation for enabling classic context menues is there: https://winaero.com/how-to-enable-full-context-menus-in-windows-11/
So if we don't go with the idea of an option we may need to check (both in the installer and the GUI?) that HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32 is not set in addition to the test on Windows 11 (I can survive if the user changes his config and is not finding the menu until MediaInfo GUI is launched again)
@cjee21 I received this use case of a user not finding anymore MediaInfo in the context menu:
I use a tool called "Winaero Tweaker" ( https://winaero.com/winaero-tweaker/ ) Luckily this tool explains what it does for (nearly) every tweak it contains and so their explanation for enabling classic context menues is there: https://winaero.com/how-to-enable-full-context-menus-in-windows-11/
So if we don't go with the idea of an option we may need to check (both in the installer and the GUI?) that
HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32is not set in addition to the test on Windows 11 (I can survive if the user changes his config and is not finding the menu until MediaInfo GUI is launched again)
I expect this is due to same Windows bug and that it will be working after #997.
When I mentioned
I just tried setting Windows to only use the old menu and MediaInfo is still present there.
in a post above, I am doing it with a similar registry tweak manually. This registry tweak just makes Windows go straight to the classic menu instead of opening the new one, nothing else as far as I know. Same behaviour as holding shift before right click. If it does not appear after this tweak, it will not appear in the classic menu without this tweak either.
As I mentioned earlier, the new shell extension although is needed to appear in the new menu, actually has nothing to do with Windows 11 or the new menu and will still work without the new menu. If it doesn't something is wrong somewhere and reverting to old shell extension will be just a workaround rather than addressing the cause.
The Verb Id Windows bug addressed in #997 actually existed since Windows 10 in 2021. Since Windows 10 only has one type of context menu, it results in totally no entry. NanaZip originally received report of this bug in 2021 and someone only found the workaround in 2022.
I expect this is due to same Windows bug and that it will be working after https://github.com/MediaArea/MediaInfo/pull/997.
I asked to test the new build, we'll see. Note that it seems that it does not resolve the issue for everyone, this person still has the issue with Total Commander.
As I mentioned earlier, the new shell extension although is needed to appear in the new menu, actually has nothing to do with Windows 11 or the new menu and will still work without the new menu. If it doesn't something is wrong somewhere and reverting to old shell extension will be just a workaround rather than addressing the cause.
If we can find the issue for (mostly) everyone, it is fine for me...
NanaZip originally received report of this bug in 2021 and someone only found the workaround in 2022.
And good that you found the thread there!
Note that it seems that it does not resolve the issue for everyone, this person still has the issue with Total Commander.
If it appears in Windows File Explorer classic menu but not in Total Commander then it is an issue with Total Commander. If it does not appear in Explorer classic menu too then it may be some Windows bug again. In that case reverting to old shell extension is not really a solution as it will then be gone from the new menu.
To better determine causes, think we need info about Total Commander version, is it 64 or 32 bit, how many shell extensions are installed (maybe Windows has a bug that stops parsing verb ids at a certain letter after some limit). I also wonder if Microsoft is aware of the bug since it seems to remain from Windows 10 2021 to Windows 11 2024. If it is really caused by some limits then there may be more issues as more apps installed by a typical user adopt the new shell extension.
In that case reverting to old shell extension is not really a solution as it will then be gone from the new menu.
Well, it was working with the old shell extension so it is a solution, but I understand that you want to try to avoid that.
For the moment I wait for feedback from the Winaero user, it the new binary does not work the first thing to implement is to check the indicated registry entry, I think, for checking if this registry entry is a good trigger, I guess. Anyway, let's wait for the feedback.
We should fix/workaround any bugs with the new shell extension as much as possible first. Else there will be more issue reports from Windows 10 users when shell extension is implemented for the Store version. There will be no old shell extension or new context menu as a workaround in the case of Windows 10 + Store app. It will just be no context menu entry.
Also note that the registry tweak is undocumented and the key may be changed by Microsoft.
I specifically checked Winaero Tweak Classic Full Context Menu. With a developer build 24.12.20241216, the menu item is in an Explorer and in Total Commander, on files and folders.
🤔 Checking for HKCU\Software\Classes\CLSID\{86ca1aa0-34aa-4e8b-a509-50c905bae2a2}\InprocServer32 will only workaround for people who have used this tweak. Since the issue has nothing to do with this tweak, it will not workaround for others that have the issue but not using the tweak (if there are any remaining). It will also cause 'regression' for those not having issues but are using the tweak by forcing a 'downgrade' to old shell extension that doesn't support opening multiple files in the same MediaInfo instance.
Found https://github.com/m2team/NanaZip/issues/505#issuecomment-2511086162 which seems similar to our issues.
So I inspect what BandiView does and it also uses packaged shell extension with a Verb Id of BandiViewShellMenu. That starts with a letter before "C" which is also used by NanaZip! So is there a bug in Windows that stops parsing shell extensions ~at a certain limit~when there is a problematic shell extension and parses in alphabetical order? IF this is true, Microsoft needs to fix this or it will be never ending. Once developers know about this we may end up with a race of who has the earliest alphabet and Verb Ids will end up being "aaaaMyShell". 🤣
PS: and BandiView is another app that wastes space by bundling Assets in the sparse package that is not supposed to contain anything other than the manifest.