FireFox 3.6 behavior when opening tabs
Pascal Sartoretti
which is very useful to reduce the number of open windows.
Up to FF 3.5, its behavior was to open the new tab(s) AT THE END of the
list of currently open tabs. With FF 3.6, the behaviour is now to open
the new tab RIGHT AFTER the current tab.
Frankly, I think that both solutions have use cases where one is better
than the other. But as a long time FireFox user, this change of behavior
is very annoying, and I would like to know which good reason(s) lead to
this change.
Pascal
Thomas Stache
> Frankly, I think that both solutions have use cases where one is better
> than the other. But as a long time FireFox user, this change of behavior
> is very annoying, and I would like to know which good reason(s) lead to
> this change.
Imagine you have a boatload of tabs open, so that the tab bar overflows
and scrolls. Now you're reading a news portal, like CNN. As you open
articles for reading in new tabs, they are now next to your current CNN
tab, instead of out-of-sight at the end of the tab list.
If you open a new empty tab (e.g. by hitting Ctrl-T), or a bookmark, the
tab is still opened at the end of the tab list, as it's not related to
the current page...
David McRitchie
And that is exactly the reason that we want to add tabs to the far right
so as not to be distracted by minor articles from links.
To fix the problem in Firefox 3.6 with tabs opened from links
browser.tabs.insertRelatedAfterCurrent set to False
Read tabs from left to right and getting rid of tabs
where the article has been read and won't be referred to
again while the other tabs are up.
To fix the problem of tab scrolling.
There is no need to have the tabs bar scroll. You can certainly view
at least 120 tabs with at least 1/2 of the favicon visible. Should be
no problem as long as the tab drop down is not screwed up by purty
pictures of web pages.
http://userstyles.org/styles/9043
--
HTH,
David McRitchie, extensions I use are briefly documented on my site
Firefox Custom: http://www.mvps.org/dmcritchie/firefox/firefox.htm
Pascal Sartoretti
> problem in Firefox 3.6 with tabs opened from links
> browser.tabs.insertRelatedAfterCurrent set to False
Thanks !
I understand why someone might prefer the "insert after current" mode,
but I am surprised that it has become the *default*. Imagine a page with
5 links to e.g. pictures or entries in a discussion : if I control-click
on the links 1 to 5 in this order, it would be logical that the order of
the tabs is also 1 to 5 (and not 5 to 1 as it is now by default).
Maybe I am being picky, but FireFox's greatness also lies in its default
values...
Pascal
Boris Zbarsky
> I understand why someone might prefer the "insert after current" mode,
> but I am surprised that it has become the *default*. Imagine a page with
> 5 links to e.g. pictures or entries in a discussion : if I control-click
> on the links 1 to 5 in this order, it would be logical that the order of
> the tabs is also 1 to 5 (and not 5 to 1 as it is now by default).
Have you actually tried this before raising it as a problem? The
default order is in fact 1 to 5.
-Boris
Pascal Sartoretti
You are 100% right, and I humbly apologize.
However, it means that the new mode is not simply "insert after current"
but "insert after current and all others links already opened from the
current page". I will try to see if I can live with it...
Mike Beltzner
> Frankly, I think that both solutions have use cases where one is
> better
> than the other. But as a long time FireFox user, this change of
> behavior
> is very annoying, and I would like to know which good reason(s) lead
> to
> this change.
http://beltzner.ca/mike/2009/01/11/a-small-change-to-tab-ordering-coming-soon-to-trunk/
cheers,
mike
Nickolay Ponomarev
Only if you stay on the parent page while clicking. If you ctrl+click links
1-3, switch tabs (e.g. to chat in gmail), then ctrl+click links 4-5, you get
this: [parent page] [4] [5] [1] [2] [3].
I understand that coming up with a well-working and non-confusing heuristic
for this is hard, and I like this change overall, but its behavior is often
unintuitive.
FWIW, Chrome uses a different heuristic for this, which doesn't fail in this
case.
Nickolay
Mike Shaver
> Only if you stay on the parent page while clicking. If you ctrl+click links
> 1-3, switch tabs (e.g. to chat in gmail), then ctrl+click links 4-5, you get
> this: [parent page] [4] [5] [1] [2] [3].
>
> I understand that coming up with a well-working and non-confusing heuristic
> for this is hard, and I like this change overall, but its behavior is often
> unintuitive.
>
> FWIW, Chrome uses a different heuristic for this, which doesn't fail in this
> case.
Could you detail the Chrome heuristic? I think the behaviour change
across tab switch is something we should look at fixing, since IMO
it's what makes the current behaviour hardest to predict.
Mike
Nickolay Ponomarev
Sorry, no. Let's hope someone else can -- their code seems to be quite
readable:
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tabs/ . FWIW,
the implemented heuristics are not documented at
http://dev.chromium.org/user-experience yet.
Nickolay
Mike Beltzner
> Sorry, no. Let's hope someone else can -- their code seems to be quite
> readable:
From experimentation, Chrome's heuristic seems to be:
"Open tabs in a left-to-right stack to the immediate right of the
parent; if the user switches to a child tab and then back to the
parent tab, the next set of tabs opened from that parent should be
appended to the existing stack. If the user switches to a non-child
tab and back to the parent, the next set of tabs opened from that
parent should create a new left-to-right stack to the immediate right
of the parent."
FWIW, this would not cover the case that Nickolay spoke of originally;
switching to another tab (to read an email or otherwise) and then back
again resets the concept of the "stack" of child tabs.
I think there's already a bug on modifying our behaviour to match the
heuristic, above. I also tend to agree with it, though I might make an
additional exception for Nickolay's case, where a single switch to
another tab and back should not interrupt the creation of a "stack",
not just a switch within. Any deeper than that and I think the
behaviour would be more confusing than beneficial.
(I didn't inspect the code, BTW; tried, but wasn't anything glaringly
obvious in the tests or comments)
cheers,
mike
Nickolay Ponomarev
> On 2009-11-04, at 8:26 AM, Nickolay Ponomarev wrote:
>
> Sorry, no. Let's hope someone else can -- their code seems to be quite
>> readable:
>>
>
> From experimentation, Chrome's heuristic seems to be:
>
> "Open tabs in a left-to-right stack to the immediate right of the parent;
> if the user switches to a child tab and then back to the parent tab, the
> next set of tabs opened from that parent should be appended to the existing
> stack. If the user switches to a non-child tab and back to the parent, the
> next set of tabs opened from that parent should create a new left-to-right
> stack to the immediate right of the parent."
>
> FWIW, this would not cover the case that Nickolay spoke of originally;
> switching to another tab (to read an email or otherwise) and then back again
> resets the concept of the "stack" of child tabs.
>
Hm, which version of Chrome is that? I'm using 4.0.223.16 and it seems to
forget the "child" relations less aggressively (thus covering my original
case) -- it does that on typing in a new URL, when opening links in pages
not part of the "group" of the most recent parent page, maybe in some other
cases.
Perhaps they changed it recently -- but I couldn't find the bug with the
discussion.
Nickolay
Mike Beltzner
> Hm, which version of Chrome is that? I'm using 4.0.223.16 and it
> seems to
> forget the "child" relations less aggressively (thus covering my
> original
> case) -- it does that on typing in a new URL, when opening links in
> pages
> not part of the "group" of the most recent parent page, maybe in
> some other
> cases.
I'm using 4.0.223.11, which claims to be "up to date" on OSX, and
using FARK with cmd-click to open links in new tabs.
cheers,
mike
Nickolay Ponomarev
That's weird. Are we talking about the same thing?
I just tried on the same Chrome version on OS X.
1. Open fark.com
2. Cmd+T, open google.com
3. Switch to the first tab by clicking on it, Cmd+click on a link (I clicked
on one of the "Source" icons)
4. Switch to google tab by clicking on it
5. Switch back to fark.com, Cmd+click on another link.
This results in [fark] [link1] [link2] [google]. Similar steps on Firefox
3.6 result in [fark] [link2] [link1] [google].
Nickolay
David McRitchie
A more realistic test than just one CNN site would be when you
work with multiple tabs from various places and with various
targets and techniques. So as it has come up in the past, I still see
NO justification for the change.
Order of Tabs in Tabs Bar -- Tests
Working with Multiple tabs in Firefox, recommend
* Tab Color Underscoring active/read/unread | userstyles.org (style 9023)
* Tabs Bar Minimal Size | userstyles.org (style 9043)
You can skip the rest of this nonsense if you always want all new tabs to always open at the far right by using:
browser.tabs.insertRelatedAfterCurrent user set to False -- (Most highly recommended)
Test opening of links in Background with your keyboard shortcut
(ctrl+click (default), or Ctrl+Shift+click like Opera) 21, 22, 23, 24, 25,
Test opening of links in Foreground with your keyboard shortcut
(ctrl+shift+click (default), or Ctrl+click (Shift+click in Opera) 31, 32, 33, 34, 35,
Test opening of links that have target="_blank" 41, 42, 43, 44, 45,
Test opening of links like Google into same new tab target="_new"
they will all be in the same heap with the newest at the top of the pile
within one new tab. 51, 52, 53, 54, 55
Firefox 3.5.4, Shiretoko 3.5.5pre (and Opera 10.01):
01, 21, 22, 23, 24, 25, 31, 32, 33, 34, 35, 41, 42, 43, 44, 45, 55
Namoroka (3.6b2pre ), and Minefield (3.7a1pre):
01, 55, 45, 44, 43, 42, 41, 35, 34, 33, 32, 21, 22, 23, 24, 25, 31
(with browser.tabs.insertRelatedAfterCurrent set to true by default)
IE8 (keyboard shortcuts same as Firefox defaults):
21, 22, 23, 24, 25, 31, 32, 33, 34, 35,
(test ended with only 10 tabs open and disappearance of base page (01),
tabs open VERY SLOWLY and with sound)
Google Chrome (Keyboard shortcuts same as Firefox/IE8 defaults):
01, 55, 45, 44, 43, 42, 41, 35, 34, 33, 32, 31, 21, 22, 23, 24, 25
Safari (keyed like Firefox/IE defaults):
01, 21, 22, 23, 24, 25, 31, 32, 33, 34, 35
(test ended with 41 going to a new window)
Testing Materials located at
http://www.mvps.org/dmcritchie/firefox/tab_capacity/001_with_underscore.htm
Martijn
> However, it means that the new mode is not simply "insert after current"
> but "insert after current and all others links already opened from the
> current page". I will try to see if I can live with it...
Yeah, I think I also would prefer the unconditional "insert after
current tab" behavior, instead of the "insert after current and all
others links already opened from the current page".
Regards,
Martijn
> _______________________________________________
> dev-apps-firefox mailing list
> dev-apps...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-apps-firefox
>
--
Martijn Wargers - Help Mozilla!
http://quality.mozilla.org/
http://wiki.mozilla.org/Mozilla_QA_Community
irc://irc.mozilla.org/qa - /nick mw22
Paul O’Shannessy
> From experimentation, Chrome's heuristic seems to be:
>
> "Open tabs in a left-to-right stack to the immediate right of the
> parent; if the user switches to a child tab and then back to the parent
> tab, the next set of tabs opened from that parent should be appended to
> the existing stack. If the user switches to a non-child tab and back to
> the parent, the next set of tabs opened from that parent should create a
> new left-to-right stack to the immediate right of the parent."
>
> obvious in the tests or comments)
I took a quick look at the code. It looks like the relevant stuff is
mostly in
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/tabs/tab_strip_model_order_controller.cc
- specifically TabStripModelOrderController::DetermineInsertionIndex
* For links with a forced foreground (likely the unusual case), they go
immediately right of the opener (opening from pinned tabs goes right of
all pinned tabs).
* For normally opened links in new tabs, it goes to the right of other
tabs opened from that tab
* So if A opens 1, 2, 3 - state is (A 1 2 3)
* Then 1 opens b and c - state is (A 1 b c 2 3)
* Then A opens 4 - state is (A 1 b c 2 3 4)
* New tabs at the end
That matches up with the comment you found (minus the unrelated tab
case, but I'm sure that's in the code somewhere).
> I think there's already a bug on modifying our behaviour to match the
> heuristic, above. I also tend to agree with it, though I might make an
> additional exception for Nickolay's case, where a single switch to
> another tab and back should not interrupt the creation of a "stack", not
> just a switch within. Any deeper than that and I think the behaviour
> would be more confusing than beneficial.
What's the bug number?
The way we're doing our heuristic is pretty naive. The benefit is that
the code is simple and and we're not doing too much. If we want to
improve the heuristic to match Chrome (or just make it a bit smarter),
we're going to need to track the opening tab / browser element - which
actually seems like a really good thing to be doing anyway.
Ideally we'd pull this out into a module to keep it contained, but we
could probably keep it where it is depending on how complicated the
logic becomes.
Pascal Sartoretti
better than the previous one (although very surprising at first).
There are still a few corner cases where the logic could be improved,
but globally it is already very good. Congratulations !
And sorry for having started this thread :-)
Pascal
Mike Beltzner
> * For links with a forced foreground (likely the unusual case), they go immediately right of the opener (opening from pinned tabs goes right of all pinned tabs).
> * For normally opened links in new tabs, it goes to the right of other tabs opened from that tab
> * So if A opens 1, 2, 3 - state is (A 1 2 3)
> * Then 1 opens b and c - state is (A 1 b c 2 3)
> * Then A opens 4 - state is (A 1 b c 2 3 4)
> * New tabs at the end
Right; the question is how long do they track that relationship with. I haven't been able to figure that out through experimentation; seems somewhat random, and I wonder if it's time-based. One thing I *do* find very odd is that the relationships survive tab-re-ordering. So, using your example:
* tab 1 is dragged to the left of tab A - state is (1 A b c 2 3 4)
* then 1 opens d - state is (1 A b c d 2 3 4)
I wouldn't expect this. Instead, I would expect that tab re-ordering would break the relationship and reset.
> What's the bug number?
Apparently I lied, or can't find it; go ahead and file a new one.
> doing too much. If we want to improve the heuristic to match Chrome (or just make it a bit smarter), we're going to need to track the opening tab / browser element - which actually seems like a really good thing to be doing anyway.
I was hoping we could get out of full on parent tracking, but if you think it isn't too complex to do, we should give it a shot. I don't think we need a *perfect* solution, but I do think that we need to minimally address the case of:
* C opens 1, 2 and 3 (A B C 1 2 3)
* user selects A
* user selects C
* C opens 4 (A B C 1 2 3 4)
currently for that set of operations, we end up with (A B C 4 1 2 3) which is obviously incorrect.
cheers,
mike
>
> Ideally we'd pull this out into a module to keep it contained, but we could probably keep it where it is depending on how complicated the logic becomes.
Henrik Skupin
> http://beltzner.ca/mike/2009/01/11/a-small-change-to-tab-ordering-coming-soon-to-trunk/
Have we ever had a discussion about the fact how new tabs should be
opened? Personally I have used this new feature because I really like it
that related tabs are getting opened right next to the current tab. It's
a really good speed-up when you have a lot of open tabs. Gmail is
normally one of the first open tabs and with the old behavior the
tabscrolling was really bad. So I had to move the Gmail tab further to
the right to be able to work faster. Then the new feature has been
checked in and I was able to move Gmail back to the first tab. Opening
bug reports would create a new tab right next to Gmail. That solved a
lot of scrolling but starting from now my tab list didn't grow from left
to right anymore but in the reversed order. So all tabs where shifted to
the right. During the day I was in a lot of situations were I have
opened bug reports from the Gmail tab but needed more information to
confirm, move, or verify the bug. Opening a new tab to load the wanted
web page puts the tab at the end of the tabstrip. So I have the same
scrolling behavior but in a way which is more distracting as before. In
such a situation I'm not able to easily switch between the bug report
and the informational web page. I have to scroll through the whole list
of tabs. So the first reaction was to drag the tab next to the tab with
the bug report. :/ After a couple of hours working that way I was
personally frustrated and turned off this feature because working with
the above mentioned situation takes longer as before the fix went in.
So my question would be if we could also be a bit smarter depending on
opening new tabs. Why do we want to open it always at the end of the tab
strip? Do we have a guideline somewhere I missed? I'm interested in
because personally this behavior doesn't match my expectations in around
95% of the cases.
Thanks
Henrik
Alexander Limi
> Opening
> bug reports would create a new tab right next to Gmail. That solved a
> lot of scrolling but starting from now my tab list didn't grow from left
> to right anymore but in the reversed order. So all tabs where shifted to
> the right.
I agree that this is suboptimal. Now that we open child tabs next to the
active tab (finally!), we should know when multiples children are being
opened, and open them left-to-right, since that's what you would expect in a
left-to-right world.
> Opening a new tab to load the wanted
> web page puts the tab at the end of the tabstrip. So I have the same
> scrolling behavior but in a way which is more distracting as before. In
> such a situation I'm not able to easily switch between the bug report
> and the informational web page. I have to scroll through the whole list
> of tabs.
This might be harder to get people to agree on, but I do agree with you —
now that tabs open next to the active one, I do expect new tabs to do the
same. Having behavior for new tab and child tab be different creates
cognitive dissonance (aka. "this feels weird" :).
The current implementation, while a step in the right direction, feels like
a halfway house. But I'll take it over the 3.5 behavior any day. :)
--
Alexander Limi · Firefox User Experience · http://limi.net
Thomas Stache
The "Tabs open relative" add-on implements the behaviour, that ALL new
tabs (Ctrl+T, bookmarks...) open next/close to the active tab. Just if
someone wants to try it. For me it didn't feel right, and I prefer the
behavior of 3.6b3
Firefox just can't know if you open an empty tab or a bookmark in the
course of the current task (opening close/next to the active tab), or if
you're switching to a new task (or are just briefly breaking out)... Who
wants another modifier key to distinguish "Still related" and "New
Task"? ;-)
Thomas Stache
> The "Tabs open relative" add-on implements the behaviour,...
Sheesh, I meant to add the link to the add-on:
https://addons.mozilla.org/en-US/firefox/addon/1956
Alexander Limi
> Firefox just can't know if you open an empty tab or a bookmark in the
> course of the current task (opening close/next to the active tab), or if
> you're switching to a new task (or are just briefly breaking out)...
Exactly. Which is why the behavior should be consistent, and open where you
are currently located. Having two different behaviors just gets confusing.
But I'm not trying to change this, a decision has been made, and we'll
revisit it if necessary.
What I do think we can fix is the ordering of the child tabs, so they don't
end up in a right-to-left order.
Anyway, this has been discussed to death before, I'm sure — I'm happy that
the behavior in 3.6 is an improvement, even though I personally still think
it is suboptimal. Sometimes you gotta back down, so I will. :)