Some new tabs open as independent no matter what

[Atario]

Short description

There are some ways to make new tabs open for which there doesn't seem to be any way to control the TST behavior.

Steps to reproduce

(Other methods can do the same — for example, using the Resurrect Pages addon. But for a clean install, this illustrates the issue:)

1. Set all of TST's new-tabs options to "a child of the current tab"
2. Open Firefox's Add-Ons Manager somewhere in a tree
3. Search for keywords using the Extensions section
4. It opens a new tab to AMO with the search you entered

Expected result

New tab is a child of the current one

Actual result

New tab is independent (top level tab, at the end of the tree)

Environment

• Platform (OS): Windows 7
• Version of Firefox: 70.0 (64-bit)
• Version (or revision) of Tree Style Tab: 3.1.8

[piroor]

There was a similar discussion. Please check my comment about this topic: #2391 (comment)

[Atario]

Interesting. However, it seems like if a Firefox window is the active window (I don't know if you can detect this), and a new tab is opened, generically speaking, then it should be the child of the currently active tab, since either the page opened it (the semantic tab-to-tab relationship you speak of) or I did, knowing that tab was active (intent of the user implying the relationship).

In the case where no Firefox window is the system active one, or where you can't tell whether this is the case or not, yes, I could see it being a problem trying to figure out how to do anything meaningful with that.

At any rate, the other guy's suggestion of using the "Open Tabs Next to Current" addon led me to the about:config setting browser.tabs.insertAfterCurrent, which comes out a bit wonky in some cases, but gets me most of the way to what I want (the new tab not being off in some far-flung place).

[piroor]

Thanks to advises! Inspired from your comment, I've researched again around WebExtensions API about window focus, and I've realized that Firefox provides ability to know the window is really active or not. This means that we can narrow down the context of a new tab open with window focus, like:

• When no Firefox window had focus:
  • New tab from a dropped URL text from any other application
  • New tab from a dropped non-URL text (search by the default search engine) from any other application
  • New tab with/without URL by any other application (or the OS itself)
• When any Firefox window had focus:
  • New tab from a bookmark
  • New tab from a history entry
  • New tab from a dropped URL text from Firefox itself
  • New tab from a dropped non-URL text (search by the default search engine) from Firefox itself
  • New tab with/without URL by Alt-Enter on the location bar
  • New tab from Firefox's UI like about:addons (this is the case reported at this issue)
  • And all other cases

Sadly new tabs from about:addons are still buried in more other cases, so we need more something information to narrow down cases.

I have another idea: a special detection like "when a new tab with addon page is opened while about:addons was active". But this is just an idea, and I have a concern that this may make things more complex with too flexible configuration UI...

[piroor]

I've implemented the idea I wrote at the last my comment, with 86297bb. Now search result tabs will become child of the addon manager tab - when both two tabs match to a specific pattern: the parent is /^about:addons/, the child is /^https:\/\/addons.mozilla.org\/([^\/]+\/)?[^\/]+\/search\//.

[irvinm]

@Atario will you try the latest version to see if we can close this item or not? @piroor has made some good progress on this.

[Atario]

@irvinm, @piroor

I just tried it and the specific case I mentioned (about:addons) does work as promised. However, other cases (like from the Resurrect Pages addon) are still the same.

It seems like the right approach should be to assume any new tab is the child of the currently active tab, and then carve out exceptions from there, rather than the other way around…

[piroor]

I think we need to be careful seriously about guessing implicit relations of a new tab and the active tab. Carelessly done aggressive guessings may break things - it's horrible. TST is basically designed very conservative about this point. If you can specify the relation of a new tab and the active tab explicitly, you should do that.

On your case, the addon Resurrect Pages should specify openerTabId parameter for new tabs opened from the active tab. I can't imagine any rational reason why the author didn't do that - I think that the author just didn't know the parameter. If the Resurrect Pages addon speficies the openerTabId parameter for tabs, you'll get better experience not only with TST but other vertical tab addons also.

Thus I think that we need to ask/recommend more addon authors to use the openerTabId parameter when he tries to open a new tab from any existing tab, for better compatibility with other tab addons and user experience on Firefox itself.

[Atario]

I'll give the author of that addon a report about that, thanks.

But out of curiosity, what is it that goes wrong in making the assumption I posed?

[piroor]

Ah, I've already created a pull request: arantius/resurrect-pages#44

[Atario]

Oh haha sorry!

[Atario]

I also tried it with View Page Archive & Cache, and at first I was seeing the same problem. But after trying again some time later, its new tabs do open as children of the current tab, but somehow ignore the setting to open as the last child, instead opening as the first. Strange…

[piroor]

dessant/web-archives#15

[irvinm]

Guys, anything more do be done here or can we close this one out?

[Atario]

Nothing has been done on the other tickets I opened in the other projects nor the pull requests piroor made, but I suppose unless we're considering changing the assumptions about intent as discussed earlier, then probably that's it for this one…?

[irvinm]

I guess I was thinking that if there wasn't anything to be done on the TST side we could close this out. I do realize that @piroor has been helping to get the other addons to make changes on their side and I am sure he will continue to help as possible even with this issue closed. (Basically, I don't think we necessarily want to wait till everything is fixed with the other addons until we close this)

[irvinm]

@piroor can we close this one?