User Agent: Mozilla/5.0 (Windows NT 10.0; rv:72.0) Gecko/20100101 Firefox/72.0

Steps to reproduce:

see https://thunderbird.topicbox.com/groups/addons/T9ee761837323c4eb/contextmenu-in-browseraction-button for code example:

create menuentry:
browser.menus.create({
id: "remove-me",
title: "testop",

contexts: ["browser_action"]
});

permissions:
"permissions": [
"menus",
"messagesRead",
"menus.overrideContext"
]

but on context-click on button, nothing is shown.
This MDN page describes what to expect:
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/menus/ContextType

This is broken for composeAction and messageDisplayAction buttons as well.

How about giving those buttons a real drop-down-menu (like the "get messages" button has) if menu entries have been added, instead of adding them to the context menu? This would give a clear user feedback, when there are more usable options available.

If we stick to the context menus, do we want to add add-on management entries (remove add-on, manage add-on) as well (like firefox is doing it)?

yes and no .... dropdown would be nicer, because we know there is something, but needs more space if there are many actionbuttons.

manage addon (options) would be good, remove not really necessary - we do that elsewhere.
Please - contrary to FF - options not in top position but at bottom. Reason: if we have sone context menu, it is there primarily to initiate some action, not to manage - we can do that elsewhere, as well..

Depends on D111449

After thinking about this a bit more, I concluded, that the 3 action contexts should behave identical to Firefox. But I do want to enrich the action buttons with menus and will create dedicated *_action_menu contexts for that in another bug. The scope of this bug is to fix the broken default behavior.

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/24b73efbb9ab
Fix browser/compose/messagedisplayAction context for menus API. r=darktrojan