Delay in context menu

Apologies if this has been addressed elsewhere. I promise I did a search first! :smiley:

Since using Scrivener 3, I noticed a delay (of about two seconds) in the context menu appearing upon right-click (or whatever ctrl-click, double finger tab I use). This delay only occurs in the text editor in Scrivener, not in the binder. Is this something someone else has seen? Is there a fix?

This is not a critical thing, as it ultimately works, but it is a small annoyance.


I’d check for any items in ~/Library/Contextual Menu Items, as well as in the main /Library/Contextual Menu Items (at this point, it’s probably best to just remove anything you find there), and any text or image based Services that might be called upon when right-clicking. On a clean installation there should be no lag—but on a Mac it is possible for other programs and utilities to insert things into other program’s menus.

Thanks for your reply. The first folder does not even exist, the second is empty. I have also unticked the ‘services’ that the OS includes in the context menu. I am trying to think what it is in the menu that could cause the delay, but I can’t see anything other than the standard items. Mind you, it is only in Scrivener that I experience this.

Anyway, perhaps another case could shed some light on this.

Maybe this older thread will shed some light. Granted, I don’t think a resolution was ever found, only a culprit: the “Share” menu. I don’t even know where that is set up to be honest. I don’t think it is the Extensions:Share Menu section—I think that’s just for the share buttons you see here and there.

The only other thing I’ve seen cause delay is contextual: right-clicking on a misspelled word with a lot of suggestions can sometimes cause a lag spike.

Thanks for sharing that thread - that seems exactly the same issue. Weird though that it suddenly became a thing in the new Scrivener. And annoying that the share menu cannot be altogether removed from the context menu!

Actually the Share menu appears to have been removed at some point in Scrivener 2, I just looked and my Scrivener 2.9 has no share option in the context menu, but Scrivener 3 does. And just testing using screenrecording, Scrivener 3’s word context menu is twice as slow as Scrivener 2 (average across same 4 words in both, 60fps screen recording)

Scrivener 2: blank line = 0.096 seconds | word = 0.128 seconds
Scrivener 3: blank line = 0.096 seconds | word = 0.32 seconds

0.3 seconds is clearly perceptibly different to 0.096…

(you can use the demo version of the app screenflick to record at 60fps and visualise mouse clicks and the latency to menu display)

Thanks for clarifying this. I have also tested it for Scrivener 3 only.

Scrivener 3: blank line = 0.1 seconds | word = 2.79 seconds

Colour wheel and all.

I would also think the share menu is the culprit, although I cannot entirely justify that position. I don’t use any of the share options that Apple forces in the menu. Also, weirdly, I only get to see Messages and Twitter, whereas the share menu in for example FoldingText has a More… option there. It also works instantly there.

Ok - thanks to your suggestions I have figured it out, somehow. My laptop is managed, and the IT department has set a policy that restricts sharing. This somehow affects what happens when the context menu is invoked, presumably when loading the sharing components.

This is going to be so tedious. I almost wished it was an issue with Scrivener, because IT are not going to budge.

However: why is this only an issue in Scrivener?

I’m not sure what nontroppo means about the word menu - the word counting menu, maybe? If so, the code is identical in Scrivener 3 and Scrivener 2, so that cannot be anything in Scrivener itself causing the extra time.

As for the “Share” menu, I never removed it from Scrivener 2. However, at some point Apple made all of the “Share” commands only work with 64-bit apps, and Scrivener 2 was 32-bit, so that is probably why the “Share” menu disappeared from there, since the “Share” menu only gets added if the services are available.

The way it works is that when you open the contextual menu, Scrivener checks to see if the various services can be used with the current selection, and if so it adds the “Share” menu. I’m wondering if it’s these checks that are slow - I note that Apple’s documentation specifies running these checks on startup, although it doesn’t make clear how to then add or remove the items on the fly after startup if the user changes the availability of these items System Preferences (as it does in its own apps).

So, what I’ve done for the next update is this: instead of adding my own custom “Share” menu (which I do because Scrivener provides a custom contextual menu), I now search through the contextual menu that would be created for a standard text view and look for the original “Share” menu that Apple’s code creates. If that exists, I use that instead of my custom version. It only falls back on my custom version if it cannot be found - and my custom version uses some optimised code now too.

Could you please therefore download this build of Scrivener and let me know if this improves the speed of the context menu for you: …

Thanks and all the best,

EDIT: Cross-posted with 06nH’s reply. The reason you’re only seeing this in Scrivener (I think) is that Scrivener custom-builds its “Share” menu because it provides a custom context menu rather than using the standard Apple text view one (so that it can provide menus for styles, document links and such). Apple seems to be doing some internal magic with its own “Share” menu that speeds up its “can I use this service?” checks. This is why I’m hoping that the above build - which extracts Apple’s “Share” menu from the default menu and inserts it into Scrivener’s custom menu rather than Scrivener hand-building its own “Share” menu - will fix the issue. Let me know!

Thanks Keith. It is really amazing this help.
Just before I read the post, I deleted the profiles that cause the issue on this machine, so I have to wait for them to be pushed back on, this will be tomorrow… I’ll report back!!

Sorry, I mean the context menu when you click over a word (where the “Look up” and Share items are present), vs. when you click on a blank line and no Share menu, Look up etc are present.

The difference between blank line and a word context menu click is gone for me in the test build, both are 6-8 frames at 60fps now (~0.112s)…

Great! Thanks for testing. Clearly Apple is doing some internal magic in its Share menu validation testing that it has not documented properly.

It’s instant now. Much better. With the restrictions on my system, I now also get the More… option under the sharing options. That was not there before.

Thanks a lot Keith.