Menu items order is random

[ygoe]

Every time I start Firefox, or maybe on other events, the order of context menu items from extensions is different. It's hard to get used to clicking on a certain location if it's in a different place all the time! I always have to scan through the icons to find the one I'm looking for.

[NumeriusNegidius]

That’s weird. Did it start happen recently? Which Firefox version are you running? Are the context menu items ordered the same as the bookmarks in the Searchs folder? Are the menu items reirdered if you reorder the bookmarks? Do you have any other extension installed that might interfere?

[eberhardweber]

I can confirm that my context menu based add-ons in FF56 also reorder every time Firefox is restarted as well. I am using the add-ons FoxyLink, Pushbullet, and uBlock origin among others, and it seems that Firefox has no set order for these context items. The order seems to be to be completely random but I guess I could try to keep some form of tally between restarts.

[ygoe]

@NumeriusNegidius I'm not talking about the menu items for the search engines, in the submenu, but the main context menu itself. I have menus there for uBlock, I don't care about cookies, and finally the search. These three have any random order.

See the items in the red rectangle:

I'd really appreciate the search to be the first, always, because that's the only one of them I actually use, and often so.

The order of the search entries looks fine, I never noticed any problems with their sort order.

I don't know when that started, I only recently started using these add-ons in preparation of the dawn of the unloved Firefox 57 update. I'm at version 56 now, the latest public stable release. The older extensions I used before (ABP, SmartSearch) never had such issues, everything was always at the same place.

[NumeriusNegidius]

OK, i see what you mean! AFAICT it’s impossible for the extension to request a position, even below the divider. I’d guess Firefox loads the extensions in the order they’re ready to be loaded by your descriptions. A saner way would probably be alphabetically. I’ll see if there’s a bug already. If any of you file one, please let me know!

[alekksander]

came here to report almost same thing, except that in my understanding once the api is ready (any perspective on the subject?) search should be right under 3th entry (check pic 2 posts above) — under „search with google”. this is the way it was achieved with with old non–webext. addon called „smartsearch” and seems to be the most logical one, as it keep searching related things together.

Thank You.

[ygoe]

Yes, putting it right below the already existing search command would be appreciated. Might even replace it. (I could possibly hide the default search menu item through userChrome.css.) I guess that's a web extension API limitation, too? Very restricted that thing, barely usable for many existing extensions. Large parts of the ecosystem will be dead by tomorrow.

[eberhardweber]

According to a user, it is in fact possible to use userChrome.css for this purpose. Context menu items apparently default their -moz-box-ordinal-group property to 1, so if an element needs to be at top, it should have the value of 0. Like so:

#id { -moz-box-ordinal-group: 0 !important; }

So we can technically sort our context menu elements as long as each of them have a proper value - at least for those that we want sorted :)

[Antagony1060]

@eberhardweber: Thanks for that. For anyone wondering, this extension's context menu id is subTreeID.

It works, but only within the block of extension-added context menu items at the bottom. I was kinda hoping I could move it further up the menu to where the original search item is – or in my case was, as I've hidden it via userChrome, thus:

#context-searchselect { display: none !important; }

[Antagony1060]

Scratch that, it doesn't work. It seemed to be always coming first above the other extensions' entries but it's gone back to the bottom again now. Maybe the id needs to be something other than the label given in background.js but if that's the case I don't know what it should be.

[alekksander]

just something to cosnider: how about menu entry (before sub–menu) being clickable and going with browsers preferred search engine? this way we could have easy search with one click, and other browser default entries hidden.

[ygoe]

@alekksander That's a split menu and I don't think Firefox has that anywhere already. And very few other applications do. I don't like these split menus too much because it's very contrary to how menus traditionally work. And it's not especially usable in touch environments.

[alekksander]

i agree. it was present in old/real opera browser. handy, but confusing as hell. perhaps two entries then? one above other, plus hiding default one? or that's exactly what's impossible to do now? it seems it's sorted alphabetically.

[NumeriusNegidius]

This issue is being discussed at https://bugzilla.mozilla.org/show_bug.cgi?id=1370735. Closing this bug, since there's nothing I can do.