Treestyletab: 3.5.28 regression, incompatibility with the Bookmark Menus feature of Firefox Multi-Account Containers

[grahamperrin]

Short description

With Tree Style Tab 3.5.28: aiming to open two Outlook Web App bookmarks in different containers, in succession, causes the second tab to (re)open in the wrong container.

Steps to reproduce

1. View the bookmarks toolbar
2. add https://staffmail.brighton.ac.uk/owa/ to the bookmarks toolbar
3. add https://staffmail.brighton.ac.uk/owa/[email protected]/ to the bookmarks toolbar
4. install TST 3.5.27
5. install Firefox Multi-Account Containers https://addons.mozilla.org/addon/multi-account-containers/ 7.1.0
6. in preferences for Firefox Multi-Account Containers, enable bookmark menus
7. add two containers – _gjp4_ and _IT Service Desk_
8. open the first bookmark in a gjp4 tab
9. open the second bookmark in an IT Service Desk tab
10. close the IT Service Desk tab
11. update TST from 3.5.27 to 3.5.28
12. open the second bookmark in an IT Service Desk tab

Expected result

• an IT Service Desk tab

Actual result

• after a moment in the IT Service Desk container, the tab changes to gjp4

Workaround

• revert to TST 3.5.27

Environment

• Platform (OS): FreeBSD-CURRENT
• Version of Firefox: 81.0
• Version (or revision) of Tree Style Tab: 3.5.28

[grahamperrin]

Screen recording of the bug in a refreshed profile:

2020-09-30 22:52 Tree Style Tab issue 2730.zip

[piroor]

It is a designed behavior, but I agree that it is a regression.

In the TST Options, there are two related items: "New Tabs Behavior" => "Non-blank new tabs" => "New tab with the same website as the current tab from the location bar, bookmarks, histories, or other cases: Open as" => "a child of the current tab" and "Container:" => "Inherit from the current tab". Under these configurations, TST 3.5.28 forces to open the second tab with the container inherited from the first tab, because they have same website.

However, I forgot to think about a tab intentionally opened with non-default container when I introduced the behavior. The intentional non-default container of a newly opened tab should have a priority higher than inherited container. Thus I've introduced a change with the commit b63fa9e. Now TST does not try to reopen the second tab with an inherited container anymore.

[grahamperrin]

Thanks, will the fix be equally effective where I have four or more successively opened tabs, each in a different container?

(At the time of writing I work with four different mailboxes from the same service.)

[piroor]

Yes. They will have their containers you specified.

[piroor]

I close this because TST 3.5.31 is already available. (If you still see this problem, add comments please.)

[grahamperrin]

Fix confirmed, thank you 👍