Mark is a minimalist tab manager in the form of a browser extension that organizes tabs as you browse. With Mark, tabs are automatically grouped by domain and sorted alphabetically.
Calls to organize are made simultaneously on worker restart and when a tab is updated which due to the existence of a top-level listener, triggers the restart. Not 100% of the time but in some cases, there are race conditions between both organization calls that are run simultaneously at weird times. This hasn't been observed in any other case, for example it doesn't seem to happen when many updates are triggered as a result of multiple tabs being updated.
Sort even more predictably using subdomains, protocol, and/or title. (Specifically giving the option to sort based on subdomain which can include any number of subdomains) Simple implementation can be to stringify the reverse the order of all existing subdomains and append the page title before sorting.
For now this can handle the generic URL assigned to new tabs to change typical automatic sorting order in all cases. New tabs should be part of a custom "new" group and should be organized to the right most side of the tab collection.
Open welcome instructions using Google Docs introducing Mark in a new tab, explaining some of the first actions a user can take to get the most out of the product. (eg. Pinning the icon, configuration settings)
Button in the action context menu to consolidate the contents of all windows (There can also be a setting to enforce a single window mode where all new tabs and groups are forced to exist in the same window)
After exhausting heavy use of the API is it worth the development and maintenance cost to keep the entire tab organization tree in memory on update? This would be diffing purposes in the attempt to be more performant and regroup everything less often but have the cost of much more code and complexity by not tapping the API for everything immediately.