leslie-heinzen / tab-grouper Goto Github PK

This is a nice-to-have. Open to different ideas on implementation. Initial thoughts: Add an "X" button, visible on hover, which pops an individual group item from the list, and updates the background page's in-memory tabsStore.

Changes made in in #13 re-arranged some of the tab closing logic so that group-page tabs are closed in a separate query first. The condition in the createTab function is designed to prevent tab closing/creation if only the group tab is open. Now, if you have a group tab and one other tab open, the group tab closes, but the rest of the commands fail at the first part of this conditional.

Because the group tabs are now closed before this query is made, we can remove the data.length check from the conditional.

Switching to localStorage for the tabsStore caused a little bug in the date format displayed to the user. Previously, the lastUpdate property for a tab group was saved as a Date in the tabsStore, and then presented in Date.toString format on the Tab Grouper page.

Just your run-of-the-mill Date serialization/de-serialization problems. Easiest solution: store the Date in the tabsStore in Date.toString format.

Tab Grouper 0.5.0 with Waterfox Classic 56.2.13 build 20190820111231 on FreeBSD-CURRENT.

After adding the extension, with multiple windows open (probably three) I clicked the toolbar button.

Expected

• a Tab Grouper page, as shown at https://addons.cdn.mozilla.net/user-media/previews/thumbs/201/201777.png

Actual result

• if I recall correctly, closure of the front window – leaving two windows and no Tab Grouper page.

I'll try to reproduce the bug, and record the screen …

Currently, information about tab groups is stored in-memory, and does not persist across different browser sessions. This is by design, and adheres to the original idea for the add-on to be a temporary dumping ground for tabs.

However, there are arguments to be made for giving this data more permanence. This really just needs some more consideration.

Because localStorage saves data in string format, we will need to serialize/de-serialize with JSON.parse and JSON.stringify. Beyond that, it would not be terribly difficult to implement.

I'd like to add a confirmation modal to the close tab group button, as suggested by @rayman89 in #1. I think this is a beneficial feature for user experience. My preference would be to use a simple native browser window confirm(), by simply updating the closeTabGroupOnClick handler function.

When grouping tabs, would be nice to filter out tabs that have duplicate URLs. There's no point in storing multiples of these tabs if there is not other unique identifying information. Good candidate is to add the filter to the executeCommand backgroundPage function. Not sure if there is a filter option in the tabs query API; if it exists, this would be my preference.

This causes a somewhat confusing user experience. It's possible to have multiple Tab Grouper pages open simultaneously across two or more browser windows currently because of the way the tabs query uses the currentWindow: true option. We need to check for Tab Grouper pages across all windows and close those during grouping.

Allow the user to restore all tabs from a given tab group. Level of effort should be low to medium, depending on how we go about it.

I'd like to keep the UI incredibly simple. Perhaps a little window restore icon in the upper right of each tab group beside the close group icon. When clicked, restores all tabs in the given tab group.

This is something I did while working on the Chrome version of this extension. Just need reset the src with the icon element's onerror attribute. For now, just use the fish icon.

Currently, when the tab grouper command is executed, the data from the query is stored in the tabsStore, and then the tabs are closed using the data from the last group in the store (the group that was just created).

The tab group page then displays the new group, but filters certain URLs, including about: and moz-extension: URLs.

This creates a bit of a bug when the tab group consists solely of tabs that are filtered from view -- we just see an empty tab group after executing the query, which is not ideal.

I would like to handle this by moving the URL filtering up to the same location that we are also filtering out duplicate tabs from the group, so that the filtered URLs will actually be filtered out of the group, not just visually hidden.

Would be possible to add a filter that allows to assign tabs to windows by url regex? So that I can, for example, make sure that all the github tabs open in a group, while all the youtube tabs in another one... So that I could really get things organized automatically with less distraction.

New feature: If we are going to utilize local storage for tab groups, I think a nice feature would be to open the Tab Grouper page on browser start-up if there are any tab groups stored. We could simply check tabsStore.length to accomplish this.

Currently, we are using runtime.getBackgroundPage to retrieve functions in the add-on's background page to execute queries and manipulate the tabs store. Unfortunately, this, by design, is not available in Private Windows. From the documentation:

Also note that this method cannot be used in a private window in Firefox—it always returns null. For more info see related bug at bugzilla.

As noted in the bug report, it is possible to accomplish communication with the background page using runtime.sendMessage. In the message, we could send a function name as a string, and a list of relevant arguments to be used in the requested function to be invoked.

This will require re-factoring every event. However, I believe it will be possible to maintain functional parity across the add-on, with the benefit of allowing it to also work in Private Windows.

I think this is in step with the original idea for the add-on, and reflects the behavior added for the tab group restore.

The code change is simple. I will open a PR and consider adding this for the version 0.3.0 release.

I was testing your addon and think it has really cool functionality but was wondering if you were planing on allowing to eliminate tabs from groups, name the groups and add tabs to existing groups. Also would be nice to have a confirmation dialog or something similar when deleting a whole group in case is not intentional. Thank you.