Closed Bug 1720662 Opened 3 years ago Closed 3 years ago

Implement a tab type property

Categories

(Thunderbird :: Add-Ons: Extensions API, enhancement, P1)

enhancement

Tracking

(thunderbird91+ fixed)

RESOLVED FIXED
92 Branch
Tracking Status
thunderbird91 + fixed

People

(Reporter: darktrojan, Assigned: darktrojan)

References

Details

Attachments

(2 files)

Breaking off from bug 1628087, as it's not really what that bug's about. I don't think we need to get too specific about types, maybe:

  • mail (anything that mailTab returns true for)
  • content (web pages)
  • calendar (any calendar tab, could be split up, or not, later)
  • compose
  • address book
  • something else? for special things like about:debugging or the account settings

Pushed by geoff@darktrojan.net:
https://hg.mozilla.org/comm-central/rev/6607fb3852ad
Implement a tab type property. r=john.bieling

Status: ASSIGNED → RESOLVED
Closed: 3 years ago
Resolution: --- → FIXED
Target Milestone: --- → 92 Branch
+  /** What sort of tab is this? */
+  get type() {
+    switch (this.nativeTab.mode.name) {
+      case "folder":
+      case "glodaList":
+        return "mail";

It isn't really accurate to call this "mail", IMO it should be "messageList", indicating 3pane tab.

I have no opinion about mail being good or bad (however, it was called mailtab before already and I did not hear complaints), but "messageList" should not be used as we might get a dedicated tab with type "messageList", which contains the message list.

But the 3pane is already and always a message list, I don't see, even theoretically, why there would be another tab type for a message list. The actual message list is #threadtree, shared between 3pane and search (Bug 297251); is there a plan to make that a tab? Note that "glodaList" is 3pane without the folderpane displayed.

We are not talking about an actual tab. The 3pane includes the folderList, the messageList and the messageDisplay. folderList and messageList are not yet accessible to WebExtensions. The messageDisplay is already a tab/browser and accessible.

I just do not want to use the name messageList for the entire mailTab.

Internal names have no real relevance for WebExt API.

Ok, we need to step back. The misnamed mailTab 'class' contains 3 tab modes: folder (3pane), glodaList (3pane with folderpane hidden), and message (3pane with threadpane hidden).

Those exact names should be returned for MailTab.type (which is certainly not internal, what am I missing?). For example, one of my extensions needs to know specifically whether the tab is glodaList. Rolling 2 of them up as mail and message as messageDisplay is just not right.

There is a messageDisplay 'class' which handles what happens in messagepane (single or multimessage, etc.); using that as a tab type is incorrect - the tab type for a single message is message. Referring to the messagepane using "messageDisplay" is correct. If you intend to use "folderList" and "messageList" to refer to those UI elements, that's great and logical.

If the api wants to roll up whether a tab type contains messagepane (ie all 3 of the above, eg 3pane), then what they have in common in tabInfo is tabInfo.tabNode.linkedPanel == "mailContent". This currently is important due to remote browsers and the partial e10s implementation, which makes stuff hard even for an experiment.

Little add-on to test new tab types.

I have to correct my last statement, the messageDisplay type is only returned, if the message is opened in its own tab. I was assuming that a message_display_action in a mailTab would return a tab with the messageDisplay type, but it is returning mail which is consistent. So the tab object describes the entire tab and not a browser loaded somewhere in the tab. Sorry about the confusion.

To see what this patch adds: Load the attached add-on via debug add-ons / temporary install add-on and move its browser_action into the other area next to the calendar and task buttons, switch to task and click the moved browser_action. You will get back a task type.

Those exact names should be returned for MailTab.type (which is certainly not internal, what am I missing?). For example, one of my extensions needs to know specifically whether the tab is glodaList

Gloda is one of those things which we will most probably not use in names exposed to the WebExt API, as it is an internal name. Also gloda is probably going to be replaced by something else in the not so far future.

You can already see if the folderpane is hidden or not in the MailTab type of the MailTabs API. Is that not sufficient for your use case?

Comment on attachment 9231483 [details]
Bug 1720662 - Implement a tab type property. r=john.bieling

[Triage Comment]
The tab type property introduced in this bug is needed for bug 1721380.

Attachment #9231483 - Flags: approval-comm-beta+
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: