New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider adding the browser.tabs.insertRelatedAfterCurrent behavior to the GUI prefs #874

Closed
lydell opened this Issue Apr 15, 2015 · 13 comments

Comments

Projects
None yet
4 participants
@lydell

lydell commented Apr 15, 2015

In TST’s preferences, there are two options for the position of new child tabs: At the beginning or end of the tree. I actually like Firefox’s default behavior. Fortunately, it is possible to achieve this, but it is not straight-forward.

If you enter about:config, you’ll see that TST has disabled browser.tabs.insertRelatedAfterCurrent. If you try to enable it, you’ll find that you can’t. TST prevents you from doing it. What you can do, though, is to flip browser.tabs.insertRelatedAfterCurrent.override.force. Then you’ll be able to enable browser.tabs.insertRelatedAfterCurrent again, which gives the Firefox default behavior.

I think that more people than me like the default Firefox behavior and are accustomed to it. Perhaps it should be exposed in TST’s preferences, as a third option for the position of new child tabs?

(I’d also be interested in knowing more about why TST goes through the trouble of creating browser.tabs.insertRelatedAfterCurrent.backup, browser.tabs.insertRelatedAfterCurrent.override and browser.tabs.insertRelatedAfterCurrent.override.force, and then listens for changes on them.)

@zewt

This comment has been minimized.

Show comment
Hide comment
@zewt

zewt May 24, 2015

Thanks, I was about to go digging to implement this. This behavior is nicer, because when you middle-click a bunch of search results, they end up at the top of the children in the order you clicked them, where the "open on top" option reverses the order.

Note that "Append to the last of the tree" in Tree needs to be selected for this to work. If you have "top of the tree" selected and do this, tabs will open in strange places (which is probably why insertRelatedAfterCurrent is forced off).

zewt commented May 24, 2015

Thanks, I was about to go digging to implement this. This behavior is nicer, because when you middle-click a bunch of search results, they end up at the top of the children in the order you clicked them, where the "open on top" option reverses the order.

Note that "Append to the last of the tree" in Tree needs to be selected for this to work. If you have "top of the tree" selected and do this, tabs will open in strange places (which is probably why insertRelatedAfterCurrent is forced off).

@piroor

This comment has been minimized.

Show comment
Hide comment
@piroor

piroor Nov 6, 2015

Owner

I think Firefox's default behavior and TST's behavior are very similar and confusable. It is very odd when new tabs are opened at middle of child tabs. Firefox's behavior (temporary relation of tabs) is not bad for flat tabs, because people possibly forget relation of tabs - which tabs are opened from another. On the other hand, TST persists relation of tabs as "tree", so you never forget relation of tabs. These different relations in just one tab bar conflict to each other. TST disables Firefox's behavior to avoid such confusion - this is an intentional decision.

Owner

piroor commented Nov 6, 2015

I think Firefox's default behavior and TST's behavior are very similar and confusable. It is very odd when new tabs are opened at middle of child tabs. Firefox's behavior (temporary relation of tabs) is not bad for flat tabs, because people possibly forget relation of tabs - which tabs are opened from another. On the other hand, TST persists relation of tabs as "tree", so you never forget relation of tabs. These different relations in just one tab bar conflict to each other. TST disables Firefox's behavior to avoid such confusion - this is an intentional decision.

@piroor piroor added the wontfix label Nov 6, 2015

@lydell

This comment has been minimized.

Show comment
Hide comment
@lydell

lydell Nov 6, 2015

Alright, you decide. Now that I've found a way to get back to Firefox's default behaviour, I'll simply stick to that. Thanks for a great addon!

lydell commented Nov 6, 2015

Alright, you decide. Now that I've found a way to get back to Firefox's default behaviour, I'll simply stick to that. Thanks for a great addon!

@lydell lydell closed this Nov 6, 2015

@zewt

This comment has been minimized.

Show comment
Hide comment
@zewt

zewt Nov 6, 2015

See my comment above for why this behavior is very painful. If I middle-click five search results, the tabs should be in the order I clicked them, not backwards. I'm clicking them in priority order, so I can ctrl-pgdn through them in that order. Please stop making users jump through obscure hoops to choose the options that they want.

zewt commented Nov 6, 2015

See my comment above for why this behavior is very painful. If I middle-click five search results, the tabs should be in the order I clicked them, not backwards. I'm clicking them in priority order, so I can ctrl-pgdn through them in that order. Please stop making users jump through obscure hoops to choose the options that they want.

@lydell

This comment has been minimized.

Show comment
Hide comment
@lydell

lydell Feb 14, 2016

@piroor I just installed Tree Style Tab 0.16.2016021201 and read this in the changelog:

Gave up to disable the preference browser.tabs.insertRelatedAfterCurrent. Now TST respects the default behavior for the preference, about new tabs opened from links.

As I understand it, TST is supposed to open tabs the same way as default Firefox does? However, as far as I can see tabs are always opened at the end of the tree.

Here is what I did:

  1. Created a new profile.
  2. Installed TST (the version mentioned above).
  3. Opened some webpage. Let’s call this tab A.
  4. Right-clicked a link in that webpage and chose “Open Link in New Tab”. Let’s call it tab B. It became a child of tab A as expected.
  5. Selected tab B, and then went back to tab A again.
  6. Opened another link in tab A, just like in step 4. Let’s call it tab C.

Actual: Tab C is opened as a child of A, at the end of the tree.
Expected: Tab C is opened as a child of A, at the start of the tree (because I visited tab B before opening tab C).

I know that we disagree on whether the default Firefox behavior is useful, but I thought I’d ask anyway :)

  • Is this a bug?
  • Is there a way to get the default Firefox behavior using the latest TST version?
  • Can we clarify the changelog?

Firefox version: 44.0.1.

lydell commented Feb 14, 2016

@piroor I just installed Tree Style Tab 0.16.2016021201 and read this in the changelog:

Gave up to disable the preference browser.tabs.insertRelatedAfterCurrent. Now TST respects the default behavior for the preference, about new tabs opened from links.

As I understand it, TST is supposed to open tabs the same way as default Firefox does? However, as far as I can see tabs are always opened at the end of the tree.

Here is what I did:

  1. Created a new profile.
  2. Installed TST (the version mentioned above).
  3. Opened some webpage. Let’s call this tab A.
  4. Right-clicked a link in that webpage and chose “Open Link in New Tab”. Let’s call it tab B. It became a child of tab A as expected.
  5. Selected tab B, and then went back to tab A again.
  6. Opened another link in tab A, just like in step 4. Let’s call it tab C.

Actual: Tab C is opened as a child of A, at the end of the tree.
Expected: Tab C is opened as a child of A, at the start of the tree (because I visited tab B before opening tab C).

I know that we disagree on whether the default Firefox behavior is useful, but I thought I’d ask anyway :)

  • Is this a bug?
  • Is there a way to get the default Firefox behavior using the latest TST version?
  • Can we clarify the changelog?

Firefox version: 44.0.1.

@piroor

This comment has been minimized.

Show comment
Hide comment
@piroor

piroor Feb 14, 2016

Owner

It's not a bug but a designed behavior of TST.

Old TST always set the preference browser.tabs.insertRelatedAfterCurrent to false. This introduced an unexpected side effect: new tabs opened by other addons were not made children of the current tab. (See also Firefox's code. When the preference is false, Firefox opens new tabs at the end of the tab bar always.) To fix this "problem", I had to inject codes to call TST's API for other conflicting addons.

On the other hand, now TST don't modify the preference anymore. New tabs opened by other addons are internally moved next to the current tab, but TST cancels the movement and re-place the tab based on TST's own configuration at the next to the existing last child tab.

I know that we disagree on whether the default Firefox behavior is useful, but I thought I’d ask anyway :)

I think that Firefox's default behavior is confusable a little for people with vertical tree tabs, because it is hard for people to forecast where a new tab is opened at. For example, 1) you open two background tabs B and C from A, 2) select C, 3) back to A, and 4) open another new child tab D from A, then child tabs are shown as D, B, and C, instead of B, C, and D. Then I think: "why the new tab D doesn't appear after C, even I open D after C?" Instead I designed TST that people easily forecast where a new tab appears at. New child tab will always appear at the top or the bottom of existing children by the configuration - there is no exception.

Firefox's default behavior seems good for horizontal tab bar without tree, because people easily give up to forecast where a new tab appears at. We human cannot remember complex relations of tabs completely with such flat tabs with no hint. However, vertical tree of tabs visualizes relations of tabs clearly. On such a situation, a behavior for flat tabs seems not good for me.

Owner

piroor commented Feb 14, 2016

It's not a bug but a designed behavior of TST.

Old TST always set the preference browser.tabs.insertRelatedAfterCurrent to false. This introduced an unexpected side effect: new tabs opened by other addons were not made children of the current tab. (See also Firefox's code. When the preference is false, Firefox opens new tabs at the end of the tab bar always.) To fix this "problem", I had to inject codes to call TST's API for other conflicting addons.

On the other hand, now TST don't modify the preference anymore. New tabs opened by other addons are internally moved next to the current tab, but TST cancels the movement and re-place the tab based on TST's own configuration at the next to the existing last child tab.

I know that we disagree on whether the default Firefox behavior is useful, but I thought I’d ask anyway :)

I think that Firefox's default behavior is confusable a little for people with vertical tree tabs, because it is hard for people to forecast where a new tab is opened at. For example, 1) you open two background tabs B and C from A, 2) select C, 3) back to A, and 4) open another new child tab D from A, then child tabs are shown as D, B, and C, instead of B, C, and D. Then I think: "why the new tab D doesn't appear after C, even I open D after C?" Instead I designed TST that people easily forecast where a new tab appears at. New child tab will always appear at the top or the bottom of existing children by the configuration - there is no exception.

Firefox's default behavior seems good for horizontal tab bar without tree, because people easily give up to forecast where a new tab appears at. We human cannot remember complex relations of tabs completely with such flat tabs with no hint. However, vertical tree of tabs visualizes relations of tabs clearly. On such a situation, a behavior for flat tabs seems not good for me.

@lydell

This comment has been minimized.

Show comment
Hide comment
@lydell

lydell Feb 14, 2016

Right, thanks for clarifying! :)

Then I think this part of the changelog should be reworded:

Gave up to disable the preference browser.tabs.insertRelatedAfterCurrent. Now TST respects the default behavior for the preference, about new tabs opened from links.

Because I have no idea what that is supposed to mean :)

Next up for me: On to the world of hacks to try to recreate my workflow before the latest TST version! (Don’t get me wrong here, I still think it was a good update.)

lydell commented Feb 14, 2016

Right, thanks for clarifying! :)

Then I think this part of the changelog should be reworded:

Gave up to disable the preference browser.tabs.insertRelatedAfterCurrent. Now TST respects the default behavior for the preference, about new tabs opened from links.

Because I have no idea what that is supposed to mean :)

Next up for me: On to the world of hacks to try to recreate my workflow before the latest TST version! (Don’t get me wrong here, I still think it was a good update.)

@zewt

This comment has been minimized.

Show comment
Hide comment
@zewt

zewt Feb 21, 2016

I don't know what happened, but the workaround of adjusting browser.tabs.insertRelatedAfterCurrent.override.force has broken, and now I can't get the behavior I want at all. Middle-clicking links is always just opening at the bottom of the children. I can't use Firefox like this. Please don't make me have to manually modify a plugin to restore the normal behavior that I've been using in Firefox for a decade...

zewt commented Feb 21, 2016

I don't know what happened, but the workaround of adjusting browser.tabs.insertRelatedAfterCurrent.override.force has broken, and now I can't get the behavior I want at all. Middle-clicking links is always just opening at the bottom of the children. I can't use Firefox like this. Please don't make me have to manually modify a plugin to restore the normal behavior that I've been using in Firefox for a decade...

@piroor

This comment has been minimized.

Show comment
Hide comment
@piroor

piroor Feb 21, 2016

Owner

See the configuration dialog of TST. You can open new child tab before existing first tab by preference.

However the behavior is still different from Firefox's default one. The reason why I don't respect it is here: #874 (comment) Moreover, by the change #1070, flat vertical tab bar becomes unavailable at future releases.

Owner

piroor commented Feb 21, 2016

See the configuration dialog of TST. You can open new child tab before existing first tab by preference.

However the behavior is still different from Firefox's default one. The reason why I don't respect it is here: #874 (comment) Moreover, by the change #1070, flat vertical tab bar becomes unavailable at future releases.

@zewt

This comment has been minimized.

Show comment
Hide comment
@zewt

zewt Feb 21, 2016

You're explaining why some people might not want this behavior, which is fine. Some people want it very much.

When I middle-click a batch of search results, I need them to be at the start of the tab, in the order I clicked them. I've used this behavior for going on a decade (starting with TMP) and my usage patterns have built up around it.

I had a workaround, but that suddenly broke.

zewt commented Feb 21, 2016

You're explaining why some people might not want this behavior, which is fine. Some people want it very much.

When I middle-click a batch of search results, I need them to be at the start of the tab, in the order I clicked them. I've used this behavior for going on a decade (starting with TMP) and my usage patterns have built up around it.

I had a workaround, but that suddenly broke.

@piroor

This comment has been minimized.

Show comment
Hide comment
@piroor

piroor Feb 22, 2016

Owner

Anyway I never use (clearly dislike) Firefox's default behavior with vertical tree, and I'm worrying about introducing new hidden bugs from such "annoying" codes. If the feature is must-have for me I'll fix them because I'm the prime user of this personal project. However, I have very few motivation and time to do for features I never use. Then, 3 or 4 new bug issues will be opened at here while I close 1 issue. I'm worrying that I may miss critical issue on such situation.

Owner

piroor commented Feb 22, 2016

Anyway I never use (clearly dislike) Firefox's default behavior with vertical tree, and I'm worrying about introducing new hidden bugs from such "annoying" codes. If the feature is must-have for me I'll fix them because I'm the prime user of this personal project. However, I have very few motivation and time to do for features I never use. Then, 3 or 4 new bug issues will be opened at here while I close 1 issue. I'm worrying that I may miss critical issue on such situation.

@lydell

This comment has been minimized.

Show comment
Hide comment
@lydell

lydell Feb 22, 2016

Here is a typical workflow for me:

  1. I make a search on some site.
  2. I scroll through the list of search results and open results that seem interesting in new background tabs. They are opened as children of the search results tab, and appear in the order I opened them.
  3. After a while I feel like checking my background tabs out, so I press alt+right to go to the first of them.
  4. I read through the first child tab and find it interesting, so I decide to keep the tab. Then I move on to the next tab by pressing alt+right.
  5. The next child tab turned out uninteresting, so I close the tab. That automatically takes me to the next child tab.
  6. I repeat this process of moving to the next child tab by pressing alt+right, keeping the interesting ones and closing the uninteresting ones.
  7. When I’ve gone through all child tabs I hop back and forth between the remaining child tabs to compare them.
  8. Then I decide that I’m not entirely satisfied with my search, so I go back to the parent tab with the search results list.
  9. I keep scrolling down in the search results list, and open results that seem interesting in new background tabs. I also perhaps go to the top of the page and change my search terms a little.

At this point, I want to go through my new child tabs, by using the keyboard.

  • If I set TST to open new child tabs as the first child, I can simply
    press alt+right to get to one of the new, unread child tabs. However, the child tabs will be in reverse order compared to the order I opened them! This is disorienting to me. I want to go through my new, unread tabs in the same order I opened them.
  • If I set TST to open new child tabs as the last child, I do not know of
    any convenient way of going to the first new unread child tab by using the keyboard. I either have to click the tab, or press alt+right multiple times until I get there.
  • If I could use Firefox’s default behavior, the new, unread child tabs would
    have been opened at the start of the tree, but in the order I opened them. This allows me to press alt+right to get to the first unread tab, and I get them in the order I opened them.

So, that’s my use case.

However, I just realized that, for me, it would be more logical to always open new child as the last child, because then all my search result tabs would be in the order I opened them, no matter if I chose to visit some of them before opening all of them. I now understand that my real problem is getting to the tab I want by using the keyboard.

So, what I’m going to try now is:

  • Switch the TST setting to always open new child tab as the last child.
  • Create a keyboard shortcut that takes me to the oldest unread tab.

Hope this is useful to someone.

lydell commented Feb 22, 2016

Here is a typical workflow for me:

  1. I make a search on some site.
  2. I scroll through the list of search results and open results that seem interesting in new background tabs. They are opened as children of the search results tab, and appear in the order I opened them.
  3. After a while I feel like checking my background tabs out, so I press alt+right to go to the first of them.
  4. I read through the first child tab and find it interesting, so I decide to keep the tab. Then I move on to the next tab by pressing alt+right.
  5. The next child tab turned out uninteresting, so I close the tab. That automatically takes me to the next child tab.
  6. I repeat this process of moving to the next child tab by pressing alt+right, keeping the interesting ones and closing the uninteresting ones.
  7. When I’ve gone through all child tabs I hop back and forth between the remaining child tabs to compare them.
  8. Then I decide that I’m not entirely satisfied with my search, so I go back to the parent tab with the search results list.
  9. I keep scrolling down in the search results list, and open results that seem interesting in new background tabs. I also perhaps go to the top of the page and change my search terms a little.

At this point, I want to go through my new child tabs, by using the keyboard.

  • If I set TST to open new child tabs as the first child, I can simply
    press alt+right to get to one of the new, unread child tabs. However, the child tabs will be in reverse order compared to the order I opened them! This is disorienting to me. I want to go through my new, unread tabs in the same order I opened them.
  • If I set TST to open new child tabs as the last child, I do not know of
    any convenient way of going to the first new unread child tab by using the keyboard. I either have to click the tab, or press alt+right multiple times until I get there.
  • If I could use Firefox’s default behavior, the new, unread child tabs would
    have been opened at the start of the tree, but in the order I opened them. This allows me to press alt+right to get to the first unread tab, and I get them in the order I opened them.

So, that’s my use case.

However, I just realized that, for me, it would be more logical to always open new child as the last child, because then all my search result tabs would be in the order I opened them, no matter if I chose to visit some of them before opening all of them. I now understand that my real problem is getting to the tab I want by using the keyboard.

So, what I’m going to try now is:

  • Switch the TST setting to always open new child tab as the last child.
  • Create a keyboard shortcut that takes me to the oldest unread tab.

Hope this is useful to someone.

lydell added a commit to akhodakivskiy/VimFx that referenced this issue Feb 22, 2016

Split `gl` into `gl` and `gL`
`gl` selects the most recent tab. Simple, right? But what if you open a
background tab? Which is the most recent tab now? Or if you open several
background tabs?

Previously, if you opened several background tabs and then pressed `gl`, the
last opened new background tab would be selected. That behavior just happened to
be.

In my opinion, it is more consistent if `gl` always selects the last _visited_
tab. An unread background tab has _not_ been visited (yet). This commit makes
this change.

If there is only one visited tab (but possibly several unread tabs), a
notification is shown telling that there is no most recent tab.

The `gL` command selects the oldest unread tab. This is useful when having
opened a bunch of background tabs. `gL` then lets you step them through in the
order you opened them. (If there are no unread tabs, a notification is shown.)

In other words, `gl` deals with _visited_ tabs only (from now on), while `gL`
deals with _unread_ tabs only.

The motivation for this commit came from piroor/treestyletab#874.
@sumyungguy

This comment has been minimized.

Show comment
Hide comment
@sumyungguy

sumyungguy Jun 16, 2016

Fyi, there is a new preference you can add to about:config:
extensions.treestyletab.controlNewTabPosition=false
It will allow the default Firefox behavior, where the opening location of a link in a new background tab can change, depending if you switch to another tab and then back. This may make @zewt happy, but for most people, TST's way is much more sensible - see #874 (comment) - that is, links in new tabs will always open as either the first or last child tab of the original, depending on the "Insertion position of new child tabs" setting in the "Tree" preferences.

sumyungguy commented Jun 16, 2016

Fyi, there is a new preference you can add to about:config:
extensions.treestyletab.controlNewTabPosition=false
It will allow the default Firefox behavior, where the opening location of a link in a new background tab can change, depending if you switch to another tab and then back. This may make @zewt happy, but for most people, TST's way is much more sensible - see #874 (comment) - that is, links in new tabs will always open as either the first or last child tab of the original, depending on the "Insertion position of new child tabs" setting in the "Tree" preferences.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment