Context menu takes a long time to display

Help & Support
1

Since I use beta release 13, showing the context menu by right clicking on a file in a lister sometimes takes very long. Somewhere between 30-45 seconds. In other times, it shows immediately as expected. This issue started with the first beta release I installed. It does not seem to be related to the type of the file right-clicked.

Any recommendations on what I could do to diagnose this issue? I've read about Settings> Miscellaneous> Advanced> context_menu_debug in an old post but can't find this option in current release.

Directory Opus 13.0.54 (Beta) Build 8753 x64
OS 10.0 (B:19045 P:2 T:1) SP 0.0

2

The setting is still there, and the best place to start:

image
image1496×1188 75.5 KB

3

Thanks Leo. Sorry, I missed it in the search results.

I enabled it. Where are the debug info saved or displayed?

4

Output is sent to DebugView. There's a link and details here: Crash, exit or high CPU when right-clicking certain files

5

I got some data to look at. In the attached log from DebugView, you can see the data for three calls to the open context menu command (right click on a file in a lister, an ".AHK" file if I remember well but the issue can occur for other file types).

The two first sections (with titles "NORMAL") last around half a second. But the third example (titled "SLOW") last 100 seconds. I'm not too familiar with what's going on behind the scene here but I noticed that, in the third case, the executions slows down around line "00000812".

Thanks for taking a look at it when you have time.

DOpus-Context_menu-Debug.txt (159.4 KB)

Thank you and Happy new year!

7

Am I the only one having this issue? It occurs to intermittently using DOpus latest beta release. It never happens using Windows Explorer.

In the previous post, I attached a log from DebugView. If someone has time to take a look at it...

8

It's because of DropBox registering hundreds of redundant shell extensions which all do the same thing. God knows why it does that, but it seems to accumulate them on some machines (maybe each time it is updated?).

Apparently File Explorer reacts to this by only instantiating one of the extensions and ignoring all the others. It's still very strange that DropBox leaves so much garbage in the registry and doesn't remove all the redundant old versions of itself, but it's on our list to investigate a way to do the same as File Explorer here, we just haven't got to it yet.

You can solve it for now by blocking all but one of the DropBox shell extensions under Preferences / Miscellaneous / Shell Extensions, in the Context Menu (UWP) category.

1 Like
9

Done. Thanks for the update and for the temporary solution.

1 Like
10

I've just solved this problem--a 7-second delay when right-clicking a folder or file in Opus--with your Dropbox solution. I had about 20 redundant Dropbox entries in the Context Menu (UWP) category. Thanks for the advice!
Mary

11

Which version were you seeing the problem in? Opus 13.4 should avoid the issue.

(At least in theory. It's difficult for us to test as our machines don't have all the extra Dropbox entries.)