[quote=“BenBasson, post:1, topic:12660”]
Yes, I know that the addon SDK is going to be deprecated, but I’d like to get a release out that’s going to last a bit longer than the current XUL-based one.[/quote]
As far as I understad, XUL/Overlay/XPCOM and SDK are both deprecated and will both be removed at the same time in late 2017, in about a year or less. So I do not think migrating from XUL to SDK version gets you anything. Unless the next 8-12 months or so are really that crucial, and there is an absolute need to use SDK vs XUL.
[quote=“BenBasson, post:1, topic:12660”]
WebExtensions doesn’t look like it’s going to do it for me (yet).
The only issue I have is that when I add my menu item, it appears at the end of the context menu.
Is there any way to specify the position where the menu item (submenu) will be inserted? In the XUL add-on I used to get a reference to a known context menu item with getElementById() and then use insertBefore().[/quote]
As far as I know, this was part of the reason for the SDK, and virtually the entire point of WebExtensions: No access to browser’s DOM, as it’s a security risk. Unscrupulous people could (hypothetically?) abuse carelessly written add-on code by modifying browser DOM elements remotely, from web pages. Or perhaps more commonly, unscrupulous add-on developers (before review and signing were strictly enforced) could modify “stock” UI elements to make them send private information elsewhere, or something like that.
The implication, and indeed the result, is no access to DOM, only a simplistic API which allows browser UI elements to be modified sparingly, in a highly controlled, and inflexible manner. It is a very much neutered API compared to XUL (plastic toy hammer vs a tool to do serious work - or damage).
However, they are still developing WebExtensions, and are still considering changes. Only in the past few weeks, have they added context-menus to browser_action context, for instance. This as not possible using SDK’s high-level API, but required an ugly mix of low-level SDK, and just plain old JS/XUL/Browser DOM access. The code was confusing and convoluted, and adhered to neither API.
Anyways, if there is a case to be made for custom positioning of context menu items in the context menu, it would be made by filing a bug report, possibly as a feature request. Check out Bugzilla to see if such a request has been made already. I suspect that any such request would be rejected as WONTFIX, because they adamantly want to ensure that the default browser menu items ALWAYS are the same and ALWAYS come first. Maybe if enough people request the functionality (through proper channels), it might be reconsidered, but if nobody says anything (again, through proper channels), nothing will change.
This is a point that frustrates me a lot. I’ve been learning XUL/SDK/WebExtensions simultaneously, a little at a time. The documentation often omits a statement saying that something (which was previously trivial) is not possible, and just gives very basic examples. Which leads to confusion about whether it is possible, but the example is too simple, or the answer is otherwise undocumented, or whether it is truly and wholly impossible, from now on, forever, by design, and fully intended. In WebExtensions documentation, omissions of this sort seem to be about 80% “won’t ever be possible, by design, now go away” and 15% “undocumented, because you’re telepathic and should have known” and 5% “might be possible if someone just asks by filing a well-worded bug report while rubbing a lucky rabbit’s foot”. 
