Bugzilla

I mainly would like to know if this is going in the right direction.

Lets start with the ``msgSubject`` field. Its menupopup is anonymous, so I cannot use its ID, instead I setup a global listener for onpopupshowing and catch it by looking at the trigger. I think one could (or even has to) remove the listeners for the individual menupopups now (including the menuIds array).

The subject field is not really content, but returning the same tab which is returned by a composeAction button seems plausible. Providing a PageURL seems not useful.

Now to the address fields. The global onpopupshowing listener also triggeres on all ``textbox-contextmenu`` popups which is apparently used if elements (and any of their parents) do not have a contextmenu specified. This is the case for a lot of input fields:
* the address fields in the composer, 
* the search fields in the main-3-pane,
* the search field in the address book,
* the search field in the chat
* any input field in the preference tab
* ...

and also on some fields which are already part of the editable context:
* any input field of loaded content pages (for example ATN)
* any input field in the add-on manager (which is probably due to proxy-context-menu used in https://searchfox.org/mozilla-central/source/toolkit/mozapps/extensions/content/aboutaddons.html#66 which )

I guess we cannot and should not add all these fields to the editable context. I do think the searchfields (in chat, addressbook and mail-3-pane) and the address fields should be part of the editable context, for the sake of continuity. To get that done, I need to be able to identify them and the best option for that is to get bug 1693577 landed. But is it the right approach in general?

In this patch I also added the addresspills themselves to the editable context, just to see if it is working, but I think - if we expose it - it needs its own context. Should we?

I mainly would like to know if this is going in the right direction.

Lets start with the ``msgSubject`` field. Its menupopup is anonymous, so I cannot use its ID, instead I setup a global listener for onpopupshowing and catch it by looking at the trigger. I think one could (or even has to) remove the listeners for the individual menupopups now (including the menuIds array).

The subject field is not really content, but returning the same tab which is returned by a composeAction button seems plausible. Providing a PageURL seems not useful.

Now to the address fields. The global onpopupshowing listener also triggeres on all ``textbox-contextmenu`` popups which is apparently used if elements (and any of their parents) do not have a contextmenu specified. This is the case for a lot of input fields:
* the address fields in the composer, 
* the search fields in the main-3-pane,
* the search field in the address book,
* the search field in the chat
* any input field in the preference tab
* ...

and also on some fields which are already part of the editable context:
* any input field of loaded content pages (for example ATN)
* any input field in the add-on manager (which is probably due to proxy-context-menu used in https://searchfox.org/mozilla-central/source/toolkit/mozapps/extensions/content/aboutaddons.html#66 which is needed for the inline options)

I guess we cannot and should not add all these fields to the editable context. I do think the searchfields (in chat, addressbook and mail-3-pane) and the address fields should be part of the editable context, for the sake of continuity. To get that done, I need to be able to identify them and the best option for that is to get bug 1693577 landed. But is it the right approach in general?

In this patch I also added the addresspills themselves to the editable context, just to see if it is working, but I think - if we expose it - it needs its own context. Should we?