Feature request: (Better) compatibility with Sync Tab Groups addon

[cosmicdan]

Hi there,

Since leaving classic Firefox, Session Manager addon has been sorely missed. However, Sync Tab Groups performs similar functionality - and quite well.

However, it initially had no support for restoring tab trees. The author was kind enough to get it working, however it is broken since 2.4.0 (sort of - the tabs restore wrongly) and I don't know why. I did try disabling the new cache option but to no avail. I've since downgraded to 2.3.0.

Please see the issue at Sync Tab Groups for more details: Morikko/sync-tab-groups#26

It would be great if you guys could sort out some compatibility, as the combo of these two is absolutely essential for a great power-users Firefox IMO! Baffles me that nobody has made this kind of request yet.

[piroor]

Thanks. The commit a170b4c should fix this problem.

[cosmicdan]

Sorry to say it's not fixed with 2.4.3 :(

Original session:

After switching back to this session:

[Morikko]

Hi @piroor

I am the developer of Sync Tab Groups. For creating the tree, Are you using only the parentId property ?

[piroor]

@Morikko TST constructs tree of tabs from some different triggers:

• Case 1: from session information stored by browser.sessions.setTabValue().
  • Session restoration done by Firefox (startup, crash recovery)
  • Undo Close Tab command of Firefox
• Case 2: from openerTabId. New tab with opener information will be attached to the specified "parent".
  • New tab from links by Firefox itself
  • Tabs opened by other addons with the openerTabId option (Sync Tab Groups seems to be this case)
• Case 3: from moved tabs. When a tab is moved in a middle of an existing tree, then the moved tab will be attached to the existing tree from its new position.
  • Drag and drop on the top tab bar
  • Tabs opened by other addons with the index option
• Case 4: from user's operations to attach/detach tabs. Tabs are intentionally attached to the specified parent.
  • Drag and drop on the sidebar
  • API call

[Morikko]

Hi @piroor
I am well in Case 2 bullet 2.

Actually, since v0.5 I opened my tabs first and next updated the openerTabId (I was waiting to have the full cross reference between old and new ids).

I changed my code to add the openerTabId at the opening stage. It implies that the parentId tab should be opened before the children. For most of the cases it works fine as I open my tabs in the same order the user let them when it closed the groups.

However, since v0.5 also I am first opening the active tab and then the other ones (before and after). I did this choice for 2 obvious reasons. Firstly, the user wants this tab so it should be loaded first. And secondly, as other tabs are "discarded", it avoid to load more than one tab at opening.

So, TST will work again (v0.6.3) except for the active tab.
Note: I update the active tab with the openerTabId once all the tabs have been opened. But TST doesn't take this in account.

[Morikko]

@piroor would it be possible to update the tree when the parentId tab value is updated (set/changed) ?

Example:

• [10] (parent: null)
• [11] (parent: null)
  --- [12] (parent: 11)

If I update 11th parent, it would switch to:

• [10] (parent: null)
  --- [11] (parent: 10)
  ------ [12] (parent: 11)

[piroor]

@Morikko I planned to do that, but sadly it is impossible for now due to restriction of WebExtensions API.

1409262 - Updated openerTabId is not notified via tabs.onUpdated if it is changed by tabs.update()
https://bugzilla.mozilla.org/show_bug.cgi?id=1409262

Of course polling based on timer will work, but I think I should wait until the bug become fixed.

[Morikko]

Of course polling based on timer will work, but I think I should wait until the bug become fixed.

Thanks for your answer, it makes totally sense. I added a message to support your request on bugzilla. I hope it will be solved quickly.

[piroor]

I close this because outdated.