[Feature Request] Auto-move "hidden unsynchronized tabs" to group

[ronjouch]

Is your feature request related to a problem? Please describe. I use Firefox Sync to send tabs, for example from my home Firefox to my work Firefox.

Sometimes, tabs arrive in one of my tab groups, but under conditions I don't understand, they instead stay stuck in limbo as "hidden unsynchronized tabs", which means they're basically lost until I think of having a look at the extension menu:

Describe the solution you'd like Rather than leaving the tabs in limbo in this menu, I'd like them to be processed by Simple Tab Groups like any tab. That is:

1. Landing in the first Tab Group catching the URL by regexp.
2. Or defaulting to the first group if no Tab Group regex matched.

Describe alternatives you've considered Alternatively to the behavior suggested above, an option Move unsynchronized tabs to <Dropdown letting user select a group> would work too.

Additional context Simple Tab Groups 3.3.4 on Firefox 66.0a1 (2019-01-24, 64-bit). Thanks for the addon! 🙂

[Drive4ik]

Hi! You have to wait next STG release v3.3.5 and in this version you can select unsynchronized tabs by Ctrl + left mouse click or Shift + left mouse click and move these tabs to custom group, like this

[ronjouch]

Hi! You have to wait next STG release v3.3.5 and in this version you can select unsynchronized tabs by Ctrl + left mouse click or Shift + left mouse click and move these tabs to custom group

@Drive4ik thanks for the fast response 🙂. My point was not about the convenience to move these tabs, it was that I'd rather never have to move them. As I wrote in my issue description,

Sometimes, tabs arrive in one of my tab groups, but under conditions I don't understand, they instead stay stuck in limbo as "hidden unsynchronized tabs", which means they're basically lost until I think of having a look at the extension menu

So rather than having to manually fish inside this bucket (which serves no purpose to me and to me is just one manual step I don't care about), I'd rather have tabs be automatically assigned a group, obviating the need for this Found unsynchronized tabs section of the UI. Does that make sense?

[Drive4ik]

As an option, I can add a check of the URL using a regular expression when launching an addon. But it seems to me that the browser makes the synchronization of tabs from the cloud slower than the addon starts, and this code simply does not work, since the tabs will appear after the tabs are synchronized (by Firefox Sync)

[ronjouch]

As an option, I can add a check of the URL using a regular expression when launching an addon. But it seems to me that the browser makes the synchronization of tabs from the cloud slower than the addon starts, and this code simply does not work, since the tabs will appear after the tabs are synchronized (by Firefox Sync)

@Drive4ik then what about checking periodically for these "hidden unsynchronized tabs"? Simple Tab Groups could set a timer to check every few seconds hidden unsynchronized tabs (which should be cheap if the API to get them is async & efficient) and, if tabs are found, send them to the relevant group (matching by regex or defaulting to first group). Does that make sense?

[Drive4ik]

No, it will not be implemented as it has unobvious behavior and further complicates the behavior and adds instability to the add-on work.

[ronjouch]

No, it will not be implemented as it has unobvious behavior and further complicates the behavior and adds instability to the add-on work.

@Drive4ik okay. I'll give it a try here, then, and will offer a PR if I get to a working patch.

One last thing I'd like to understand: I just had a tab arrive from home browser to work browser. I was in tab group 1 when the tab synced. The tab appeared in the tab row, I could see it during maybe one second, then it disappeared from the tab row and, as expected, was to be found in this hidden unsynchronized tabs section of the addon.

→ What's going on here? Does Firefox send it to the hidden tabs bucket? Or is it the addon? If the addon, what makes you say that it is impossible to send the newly-arrived tab to a group rather than sending it to the hidden bucket? Is there an API limitation I don't understand?

Thanks again.

[Drive4ik]

One last thing I'd like to understand: I just had a tab arrive from home browser to work browser. I was in tab group 1 when the tab synced. The tab appeared in the tab row, I could see it during maybe one second, then it disappeared from the tab row and, as expected, was to be found in this hidden unsynchronized tabs section of the addon.

This addon manages all tabs in the entire group. There is only one condition when, if you are in group 1 and in the address line you write the URL of the tab that is in group 2 and is currently hidden, the browser offers to switch to it. If you agree, it becomes visible, and in this case my addon switches the group and show all tabs in group 2.

But if the tab is simply hidden, and the addon has not initiated this action, then it excludes it from the current group. Maybe you have other add-ons that have the ability to control the behavior of tabs?

[ronjouch]

@Drive4ik

But if the tab is simply hidden, and the addon has not initiated this action, then it excludes it from the current group.

I'm not sure I understand what you mean by if the tab is simply hidden. Tab arrives, is not hidden, is visible in the tab bar of group 1, then after one second disappears and lands in hidden unsynchronized tabs.

Maybe you have other add-ons that have the ability to control the behavior of tabs?

Not that I know of. My addons are:

Cookie AutoDelete 3.0.1
Copy Selection as Markdown  0.8.0
Decentraleyes 2.0.8
Neat URL  4.1.5
Pin Unpin Tab 3.4
Simple Tab Groups 3.3.4
uBlock Origin 1.17.7.103 
Vimium  1.64.3

[Drive4ik]

I can say that I do not know why this tab becomes hidden. Because of the addon, this can only be when the browser is loaded, but not during normal operation.

[ronjouch]

Alright, just realize my issue is a duplicate of https://github.com/Drive4ik/simple-tab-groups/issues/274 and https://github.com/Drive4ik/simple-tab-groups/issues/278 .

Hoping maintainer / someone / I can find a workaround.

[ronjouch]

Took note of today's release 3.4 with Quick startup addon. Try to fix bugs: #334, #308, #295, #274, #278, etc. Will test and report back. @Drive4ik thanks for trying 🙂🙂🙂!

[ronjouch]

Took note of today's release 3.4 with "Quick startup addon. Try to fix bugs: #334, #308, #295, #274, #278, etc". Will test and report back. @Drive4ik thanks for trying 🙂🙂🙂!

@Drive4ik after a few days of using 3.4.1, I confirm the bug is still present. Or is it halfway-fixed? On two occasions,

1. I sent three tabs from device A to device B.
2. On starting device B's Firefox,

Expected: 3 received tabs arrive as tabs in the current group.

Actual: 2 received tabs landed in hidden unsynchronized tabs, and 1 was in the current group 😕.

Is that your experience too?

[grahamperrin]

Simple Tab Groups 4.7 added to Firefox 86.0 release candidate 3 with KDE Plasma 5 on FreeBSD 14.0-CURRENT.

Without quitting Firefox:

• a tab received whilst a group window is in front becomes grouped ☑

– then if I bring to the front a non-group pop-up window:

• the next tab received becomes grouped in the window that was previously in front ☑

– then if I bring to the front a non-group window followed by the non-group pop-up window:

• the next tab received is non-grouped in the window that was previously in front ☑

– there's a ☑ because whilst the tab is not grouped, it is expected behaviour.

If you find unpredictable behaviour for any tab that was sent whilst Firefox was not running, this randomness might be attributed to a Mozilla bug for disorderly restoration of multiple windows (where three or more were open before quit):

• 1235231 - Sessions restore windows in random order

– 2015, 413 votes (including mine).

More obscurely, maybe blocking a reliable fix for https://github.com/Drive4ik/simple-tab-groups/issues/321#issuecomment-468676751:

• 1378459 - (webextensions-startup) [meta] Allow some addon functionality to load prior to any content loading

– 2017, 96 votes.

If you have not already done so, please consider voting for bugs such as these. Thank you.