User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/78.0.3904.108 Safari/537.36

Steps to reproduce:

While you can query and manipulate emails quite well through the messages API, there is currently no way to just display/open an email returned by those APIs.
There should be a WebExtension API to open a specific email, either in the current 3-pane page, in a new tab, or separate popup window, for instance something like:

browser.tabs.create({
messageId: 123
});

or

browser.message.open(messageId, { options });

Since the messageId returned by browser.messages.query is internal and doesn't appear to relate to anything XUL or IMAP knows, there doesn't seem to be a way to work around this by using a custom Web Experiments API.

We have 3 ways to open messages

1. in a mailtab message tab

• If a given msg is loaded/selected, it must also update the selected folder and the selected message
• Should it be possible to load/select multiple messages? Do they have to be of the same folder?

2. in a new tab

3. in a new window

• support eml string as source as well?

What else do we have to think of?

I think the messageDisplay API is the correct location for this?

That all sounds good to me. Now you get to choose from the numerous ways of doing each operation.

(In reply to John Bieling (:TbSync) from comment #1)

• Should it be possible to load/select multiple messages? Do they have to be of the same folder?

I think we need three things:

• a way to open individual messages in new tabs/windows
• a way to open a view with a group of messages (that is, a folder or a search result, or just an array of messages the extension came up with)
• a way to select any number of messages in such a view

The first is simple enough.

The second should be easy for a folder. It is possible to do for searches (we already do, if you click on "show results as list" in a search tab) and therefore should be possible for arbitrary groups of messages.

We've already got mailTabs.update which can set the displayed folder. Perhaps we should extend that to handle your #1 and my third item, especially since it controls things like the visibility of the preview pane.

In general, maybe this should just be the ability to open mid: urls. Is there perhaps a different api already to open links/urls?

We only have https://webextension-api.thunderbird.net/en/91/windows.html#opendefaultbrowser-url which is limited to opening webpages and that is why it has been added to the windows API.

There is a request to open general links and let Thunderbird handle the application to open it with (basically removing the restriction to the http/https scheme in [1] ). This was one of my first APIs I added and back then I could not get my head around where to add a general url-open-method. And I still don't. Ideas? That could then also open mid: urls.

But opening a message can be done in a new tab, in a new window and in the current mail3-pane, so I do not know how good that mixes with a standard url-open-function which will probably only support a standard location to load the message. Furthermore, I do not know if mid: urls are unique. Don't they rely on the messageHeaderId, which is not uniqe? Using the messages API ID will open a specific message, regardless if there are multiple messages with the same messageHeaderId.

[1] : https://searchfox.org/comm-central/rev/b50797d1d141cc4265a8f9e7c6c7d29355622525/mail/components/extensions/parent/ext-windows.js#353

(In reply to John Bieling (:TbSync) from comment #7)

But opening a message can be done in a new tab, in a new window and in the current mail3-pane, so I do not know how good that mixes with a standard url-open-function which will probably only support a standard location to load the message.

One could think about that as a link with target attribute, or not. Distinguishing between open in tab vs window is more problematic, and if considering the browser equivalence, just a user preference that the api should not fiddle with.

Furthermore, I do not know if mid: urls are unique. Don't they rely on the messageHeaderId, which is not uniqe? Using the messages API ID will open a specific message, regardless if there are multiple messages with the same messageHeaderId.

Yes mids are not guaranteed to lead to the same physical copy of the message. They will lead to the same message though. It's rather unclear why anyone should care about which of the (same) messages are opened. I'm sure there may be cases, but there's certainly the case for letting perfect being the enemy of the good here.

If we introduce a message-open-API, and a developer links that to a menu entry which he added to the context menu of the message list, it should open the exact message clicked on. Otherwise, the UI could jump to a different folder which would be highly confusing.

I am totally fine with adding the capability to open mid: urls by extending the function we already have but finding a better place and name, but we also need a dedicated message open function (part of the messageDisplay API), which is ID driven and allows specifying how it should be opened (tab, preview, window).

Pushed by mkmelin@iki.fi:
https://hg.mozilla.org/comm-central/rev/988796e0f044
Add support to the messageDisplay API for opening messages in tabs and windows. r=darktrojan

@ Geoff :

I implemented:

• open single message in a new tab/window via messageDisplay.open()
• set selected message(s) in mailTab via mailTabs.setSelectedMessages() - which either loads the message or shows the multi-messages-selected view.

What is still todo is loading an arbitrary set of messages ("show results as list"). Neither the messageDisplay API nor the mailTabs API seem to be good candidates. The mailTabs API seems wrong, because that view is not a real mailTab (you cannot enable the folder pane and cannot disable the message pane).

Should we bake this into a new API? A messageList API?

• query
• getListedMessages(tabId)
  • [could be added to mailTabs API as well]
• getSelectedMessages(tabId)
• setSelectedMessages(tabId, messages)
• setQuickFilter
• open(messages)
  • [we only support that in a tab right? I was not able to trigger standalone message list windows.]
  • [we do not have a way to open a new mailTab either, so this could be added as mailTabs.open(folder) as well]
  • [alternative name: create]
• update(tabId)
  • layout
  • viewType
  • sortOrder
  • sortType

Events:

• onSelectedMessagesChanged
• onListedMessagesChanged

It does look very similar to the mailTabs API, but has a few important differences. But since I suggest giving these tabs a "messageList" type instead of using the "mail" type for these, a new API seems plausible. Even if it has almost the same interface (but it is message-centric and not folder-centric).

Instead of messageList, the name for the API could also include the word Tabs, like searchTabs or messageListTabs, to better fit with the existing naming conventions.

Figuring out what makes the most sense here will be easier once we have the new tab implementations in place. I think it should wait until then.

I move the new API into Bug 1796147 and close this one as fixed.