279574 - After closing a new tab that is a diverted new window, Firefox should return to the originating (parent) tab, but only if no tab switching has occurred after the new tab was opened

Status: RESOLVED DUPLICATE of bug 308396

(Firefox :: Tabbed Browser, defect)

Description

[mmortal03]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050122 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050122 Firefox/1.0+

Make note that all comments in this bug report are based on the situation where
the option to "Force links that open new windows to open in: a new tab" is enabled.

In this case, new tabs created using this option should behave as if they were
new windows.  There are some current situations in Firefox where they do not. 
One good case example is, while having other tabs open, a user clicks on a link
that would normally open in a new window.  Firefox smartly switches to this new
tab.  The user then does not do any more tab switching, reads what he wants, and
then closes this tab.  'Instinctively', Firefox should not switch back to the
adjacent tab, but instead to the previously viewed tab.  There is logic behind
this 'instinct', which I will get to in a second.

An alternative example:  A user, currently viewing his Hotmail junk email folder
and with other tabs open, clicks "Empty".  A new "popup tab", referably
speaking, opens.  The user clicks the "Ok" button within this "popup tab", and
the tab closes.  Firefox should then switch back to the Hotmail junk email
folder, and not the adjacent tab, as it currently does.

So, to generalize, what is the specific case where Firefox should NOT switch to
the adjacent tab when in this mode?

When a new tab has been opened from a link in a webpage, no more tab switching
occurs, and then the tab is closed by any method, Firefox should NOT switch to
the adjacent tab, but instead the previously viewed tab.

Obviously, if any tab switching occurs after this new tab is opened, but before
it is later closed, Firefox should NOT behave any differently than normally.

Here is another case scenario where this bug applies:  Popup blocking is
disabled and the user has multiple tabs open.  A "popup tab" occurs that is NOT
user initiated.  When closing this tab immediately, after no other tab switching
has occured, Firefox should switch back to the last tab that was viewed, and NOT
the adjacent tab.

Do not confuse this bug with an enhancement request to have a certain well known
TBE option to "ALWAYS switch to the last viewed tab when closing another tab"
integrated into Firefox.  This TBE option, while similar in behavior in the
situations outlined above, displays undesireable behavior when NOT in these
specific situations.  As such, this bug report only refers to these particular
case scenarios, where a similar behavior WOULD ALWAYS be desireable, and by
default.  

Specifically, in conclusion, neither standard Firefox nor TBE can *yet* properly
emulate the behavior of popup windows, when forcing them into new tabs.  The
purpose of this bug report is to rectify this.

Reproducible: Always

Steps to Reproduce:
1.  Place Firefox in "Force links that open new windows to open in: a new tab" mode.
2.  Open more than one tab.
3.  Click on a link that would normally open in a new window.
4.  Immediately close this tab.  Do not perform any other tab switching.

Actual Results:  
Firefox switches to the adjacent tab.

Expected Results:  
Firefox should have switched back to the last tab that was in focus.

Comment 1

[Dan M]

If my speed reading skillz haven't betrayed me, by my count this is the 61st
duplicate bug filed on top of ... oh gosh, I think the first one was bug 105722,
filed in 2001. There's something to be said for the duplicate count alone, but
it seems clear that filing additional duplicates isn't a good approach.
Reporter... oh, never mind. I'm closing it against the best fit urbug, rather
than the very original.

*** This bug has been marked as a duplicate of 144207 ***

Comment 2

[mmortal03]

Hmm, I specifically said what this bug WASN'T, and that is what you linked to,
what those other bug reports are about.  They are blatant requests for ALWAYS
going to the last viewed tab.  That is exactly what I am AGAINST, because it is
illogical, and when I have tested this behavior using a plugin to always do it,
it is extremely annoying and unpredictable.  This has nothing to do with
altering the very good, standard, predictable tab behavior that we now have.  

It is in only a specific case and mode where I request the behavior be altered.
 Logic dictates that in ONLY the mode "Force links that open new windows to open
in: a new tab", should we even consider this.  In any other mode, tabs have been
user initiated specifically as tabs, and should be treated as such.  In this
mode, however, windows are actually being forced to open as tabs, and in THIS
CASE should act as such.  This, and only this, is what I am referring to.

Is the issue here that the developers have decided that ACROSS THE BOARD, the
tabs should work completely identically, at all times, with no chance for well
placed, optimal, predictable, preferred logic in an advanced tab mode, of all
things?  My question for this quick marking as wontfix and/or duplicate is, how
is my bug report a duplicate and why NOT have the mode behave this way?  Thanks

Comment 3

[Dan M]

Perhaps I misunderstood after I got bogged down. One could have hoped for a more
concise problem statement. What you're asking for then, is it that the closing
of a tab gives focus to its opener tab, if any? So, the focus behaviour defined
in bug 144207 but only when closing a tab opened by a control in an older tab
that tried to open a new window but was diverted into a tab instead because of
user preferences?

Comment 4

[mmortal03]

(In reply to comment #3)
> Perhaps I misunderstood after I got bogged down. One could have hoped for a more
> concise problem statement. What you're asking for then, is it that the closing
> of a tab gives focus to its opener tab, if any? So, the focus behaviour defined
> in bug 144207 but only when closing a tab opened by a control in an older tab
> that tried to open a new window but was diverted into a tab instead because of
> user preferences?

Yes.  Only with this user preference.  I did read in one of the other bug
reports with a simpler idea that would do the job and should be applied here,
and it would fix the problem without giving these tabs "special properties" in
certain cases.  All that needs to be done is, when these tabs open, create these
tabs directly to the right of the older parent tab.  ONLY these, and ONLY in the
aformentioned cases.  That way, when they are immediately closed, you are
brought back to the originating tab, but if any more tab switching occurs, they
are still just normal tabs, but a bonus would be that they retain a relationship
to their originating tab.  Obviously, it would also make tracing any "popup
tabs" to their originating tab a trivial manner. :)

Comment 5

[mmortal03]

The only question that arrises is, how difficult is tab insertion in Firefox,
because that is all that needs to be done here.  Does Firefox use a linked list
for the tabs?  If so, this should conceptually be fairly easy to code (logic
steps): 

1.) Which is the originating tab?
2.) What is the location of the originating tab on the tab bar?
3.) Insert this new tab that would normally be a new window to the right of the
originating tab.
4.) ???
5.) Profit!

Comment 6

[mmortal03]

I have found an enhancement request that, given my proposed cure to the bug, is
inclusive of my bug report, but I would not say that my bug report is a
duplicate of it.  Basically, they are asking for MORE options and
CONFIGURABILITY and for ALL modes, not just single window mode (and even middle
clicks would open next to the originating tab).  I like what they are proposing,
and fixing their bug WOULD fix mine, but maybe we can get mine fixed, and
implement the full deal later, as theirs is much more complicated.  Their bug IS
a good reference for mine, though:

https://bugzilla.mozilla.org/show_bug.cgi?id=262459

Comment 7

[Dan M]

I still don't see an interesting distinction. Take a look at the opening comment
of bug 144207, paragraph 3. Comment 3 and 4 sound an awful lot like bug 105722
and bug 161836. But since you do see a difference I'll reopen this bug for a
second opinion.

Comment 8

[mmortal03]

I read through those, and I have found what the difference is between theirs and
mine.  I have also noticed that I need to clarify a bit.  My case refers to when
"Force links that open in new windows to open in new tabs" is enabled, but more
specifically when the links themselves would normally open content into a new
window.  This bug has nothing to do with user-initiated tabbing (eg middle
clicking, nor does it have to do with passive tabbing (tabbing links into the
background for later viewing).  

Already with this setting, normal HTML links that are targeted for a new window
will open in a new tab with focus.  Those should open right next to the page you
clicked to them from.  If browser.link.open_newwindow.restriction is set to 0, 
all javascript window.open() links are diverted to new tabs.  These should also
open next to the original tab.  If browser.link.open_newwindow.restriction is
set to 2, only javascript window.open() links with no attributes open into a new
tab.  These should open next to the original tab.  These are single case links,
and that is why this works.  If these were opened enmasse, then this would not
work, and is the problem that those other bugs run into.

To sum it up, what those other bugs refer to Primarily is when middle clicking
links.  This is not what I am refering to at all.  Though it would be nice to be
able to have the option to do THAT, as well, if a user wants to, that is not
what I am talking about.

Comment 9

[mmortal03]

I noticed that I was assuming that opening to the right would be the appropriate
action for this case.  Opening to the LEFT and focusing these types of new tabs
opening is actually the appropriate behavior.

Comment 10

[mmortal03]

Recheck that.  Having these links open to the left kills the chronological
order.  Where they open should not be changed with this bug.  This would, in a
sense, be implementing grouping, and is not the purpose of this bug, as that
would actually be an enhancement.  Leave any and all of that to Bug 262459.

The solution to this bug is simply this: When closing tabs that were diverted
from opening in new windows, if no more tab switching has occured, return to the
originating tab.  Once any other tab switching occurs, even if switching back to
one of these tabs,  closing them should be the regular, to the right,
chronological behavior.

Again, where they open should not be changed with this bug.  Taking advantage of
the location was hacking a fix, instead of just curing the bug.  I realized that
opening to the left would not be considered anyway.  This other way is elegant
and fixes the bug.

Comment 11

[mmortal03]

Renaming bug.  Please read with emphasis on "but only if no tab switching has
occurred after the new tab was opened"

Comment 12

[mmortal03]

The expected results of fixing this bug should also refer to the case of when
bookmarks are set to to open new tabs into the foreground.  In this case, when
closing this new tab before switching to another, it should go back to the
previously focused page.

If a folder of bookmarks are opened into new tabs under these circumstances (the
first of these placed into focus) after closing the first of these, it should
continue on to the right through the rest of these new tabs.  Should any special
treatment be given to the tab that was in focus before this folder of bookmarks
was opened?  I don't think it would be necessary.  Does anyone?

Comment 13

[mmortal03]

(In reply to comment #12)
> The expected results of fixing this bug should also refer to the case of when
> bookmarks are set to to open new tabs into the foreground.  In this case, when
> closing this new tab before switching to another, it should go back to the
> previously focused page.
> 
> If a folder of bookmarks are opened into new tabs under these circumstances (the
> first of these placed into focus) after closing the first of these, it should
> continue on to the right through the rest of these new tabs.  Should any special
> treatment be given to the tab that was in focus before this folder of bookmarks
> was opened?  I don't think it would be necessary.  Does anyone?

Hmm, actually, that would make it almost the same as Bug 105722, so have this
bug fix only diverted links to Single Window Mode.  Have that bug refer to all
cases, as well as "tab click memory".

Comment 14

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: test case for this feature

Comment 15

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: patch

this patch:

1. sets the defaults for preferences to force targeted link clicks and
window.open calls into new tabs; and still opens windows for windows opened
with features
2. restores focus to the tab that opened the tab that is being closed if it was
opened in the foreground by such a link click.
3. adds a boolean pref to toggle this behavior

This system seems to work pretty well, though it may not be complete. I think
it gets the 95% cases though.

Comment 16

[Mike Beltzner [:beltzner, not reading bugmail]]

While the change to the pref is, I think, the right thing to do for 1.5, adding
a bunch of code that changes the selection of a tab on close sounds like a risky
thing to be doing this close to beta. Especially since (as mconnor pointed out
to us both offline) it creates some inconsistent behaviour for
select-tab-on-close behaviour.

I think it's an interesting paradigm, and would be happy for this to land on
trunk where we can play and experiment, but don't think we should change the
tabbrowser behaviour for 1.5

Comment 17

[Chris Beard]

(In reply to comment #16)
> Especially since (as mconnor pointed out
> to us both offline) it creates some inconsistent behaviour for
> select-tab-on-close behaviour.

Could you be more specific?

Comment 18

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #17)
> Could you be more specific?

 - browser opens                        [_a_            ]
 - clicks a link that opens a new tab   [ a |_b_        ]
 - user opens a new tab                 [ a | b |_c_    ]
 - clicks a link that opens a new tab   [ a | b | c |_d_]


At this point, selecting and closing Tab C will close to the right (selecting
Tab D), but selecting and closing Tab B will close to the left (selecting a). 

I'd suggested to mconnor that we could add in logic that states "as soon as the
user has switched tab focus, stop remembering parent tabs and go back to always
closing to the right", but he pointed out that doesn't help the fact that the
user needs to remember how a tab was opened in order to understand why it's
closing one way vs. another. So, for example ..:

 - browser opens                        [_a_            ]
 - opens a new tab                      [ a |_b_        ]
 - goes back to first tab               [_a_| b |       ]
 - clicks a link that opens a new tab   [ a | b |_c_    ]
 
Now let's say I go read some email or something, and then flip back to my
browser. I need to remember that Tab C had been opened differently from Tab B in
order to be able to understand that closing Tab C will bring me to Tab A, but
selecting and closing Tab B will bring me to Tab C.

I'm not sure that this would be extremely confusing, but it is certainly harder
to predict behaviour than always close-to-the-right, and warrants a little
further study.

Comment 19

[Ben Goodger (use ben at mozilla dot org for email)]

OK - I'm with you on the "too late" for such a change angle, but in that case we
should make external app link clicks open a new window then, since I believe
forcing links that open new tabs/windows is an all or nothing thing and the app
should be internally consistent by default. 

I was already slightly skittish about external apps into new tabs instead of
windows (as IE is by default) given that many users don't understand multiple
document environments. My fears were eased though by the notion that this
particular bug would be fixed alongside them.

As for stability - we can actually keep this feature in for 1.5 and default off
via hidden pref, if we want more testing. 

Comment 20

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #19)
> I was already slightly skittish about external apps into new tabs instead of
> windows (as IE is by default) given that many users don't understand multiple

I think that tabs-instead-of-windows as a default is still the right option for
1.5, especially since tabbed-browsing is becoming more and more of a
differentiator for "browsers of the future". The current beta of IE7 shows that
they'll be defaulting new window links to tabs instead of windows as in IE6.

> document environments. My fears were eased though by the notion that this
> particular bug would be fixed alongside them.

As were mine, originally, but I think we'll still be OK. For the novice user,
who doesn't open new tabs on their own (either through "Open in New Tab" or
through Ctrl+T) the current closing behaviour is actually pretty close to what
you've got, anyway:

 - user opens browser         [_a_                ]
 - new window link            [ a |_b_            ]
 - closes that tab            [_a_                ] 

As long as the user doesn't switch tabs, they're fine. The confusing case comes
when you do something like:

 - user opens browser         [_a_                ]
 - new window link            [ a |_b_            ]
 - back to A                  [_a_| b             ]
 - new window link            [ a | b |_c_        ]
 - close tab                  [ a |_b_            ]

But at that point the user has already, in a way, expressed his desire to play
in the wacky world of multiple tabs.

> As for stability - we can actually keep this feature in for 1.5 and default 
> off via hidden pref, if we want more testing. 

That'd be grand, assuming that the patch has a low risk to the general
tabbrowser behaviour.

Comment 21

[Mike Connor [:mconnor]]

Unless we're turning this on, and I think this is too late for a change of this
nature, I'd rather not take the tabbrowser changes at all, on general principle.

Comment 22

[Ben Goodger (use ben at mozilla dot org for email)]

Microsoft is rushing into the tabbed browsing thing because they're a day late
and a dollar short. I don't expect much in the way of reasoned UI design from
them, at least not before the next beta or two, or even perhaps IE8. 

What I'm concerned about is people not noticing the tabbed strip at all when a
new window is opened. We have evidence that people don't notice the info bar,
which is about the same high, but yellow. Like the info bar, the tab strip is
transitory, rather than a permanent fixture of the browser window. 

If they don't notice the tab strip and they click on a link from an AIM window,
a new window will open "replacing" their current document and they will have
none of the ways they have traditionally been able to rely on getting back to it
- clicking the back button or using the system's window management. 

I am talking about the extreme novices here, but this has never been a "power
users" browser, even though such users tend to adopt it. 

I maintain the right decision in the absence of a comprehensive set of tabbed
browsing discovery tools is to not force the feature on people. 

Comment 23

[Ben Goodger (use ben at mozilla dot org for email)]

I also think we should at least take the restrict->3 preference setting, since
it only effects the non-default condition. 

Comment 24

[Ben Goodger (use ben at mozilla dot org for email)]

OK. We (Darin, Brian Rakowski and myself) discussed this over here a little more
and I'm posting the results of our discussion into a wiki page here:

http://wiki.mozilla.org/Link_Targeting

Comment 25

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #23)
> I also think we should at least take the restrict->3 preference setting, since
> it only effects the non-default condition.

That makes sense to me, too. Regardless of what we end up doing for our other
preferences, the default for new windows as tabs should always be to ignore
windows that are specified to open at a particular size.

> I'm posting the results of our discussion into a wiki page here:

Thanks for putting that together - I'll shift discussion of the other points
into that wiki and file more bugs as we reach consensus. Of the final
recommendations, this bug really only talks about the third one, which is to
change the on-tab-close selection behaviour.

I was thinking more about mconnor's scenarios that lead to wonky behaviour, and
stuck on his quite-right comment that people shouldn't have to remember how a
tab had been opened to understand how it will close. So, I suggest a further
optimization to the condition; it might not completely set aside the behavioural
inconsistency, but I'm all about exploring all the corners and options:

 if a link opens a new tab (from internal/external sources),
 and the user doesn't switch UI focus away from that tab,
 then closing that tab goes back to the previously focued tab in the UI.

This means that the only way for tab-close to go back to the previously focused
tab is when the user clicks a link that opens a new tab and then closes that tab
immediately. It doesn't cover the scenario where someone steps away from their
machine for a while, but it is somewhat easier to understand as "if I do nothing
but open and dispose a new tab, I always go back to where I was just before I
did that."

Comment 26

[Bradley Chapman (not reading bugmail, still gone but not forever)]

Having read through this bug and through the Wiki, I agree that the behavioural
change recommended in Ben's patch could, in the worst case, be terribly
confusing to novice users who don't understand tabbed browsing.

However, I agree with the reporter and feel that this would be a _major_
usability improvement to the tabbed browser - not just for the browser, but for
extension users as well. 

As the maintainer of TBP, I am willing to expose UI for this option in any TBP
release made available for 1.5, allowing less-than-novice users willing to
install my extension to test it out and "see what happens". In doing so I will
ask users to turn it on, try it out, and give me feedback that I can put in the
Wiki or elsewhere. If the feedback is generally good, the UI can be exposed in
Firefox itself and made available to everyone. How's that?

(As an aside, will the 1.5 recommendations involve any mods at the pref level?)

Comment 27

[Micah Bucy]

(In reply to comment #22)
> What I'm concerned about is people not noticing the tabbed strip at all when 
a
> new window is opened. We have evidence that people don't notice the info bar,
> which is about the same high, but yellow. Like the info bar, the tab strip is
> transitory, rather than a permanent fixture of the browser window. 
> If they don't notice the tab strip and they click on a link from an AIM 
window,
> a new window will open "replacing" their current document and they will have
> none of the ways they have traditionally been able to rely on getting back 
to it
> - clicking the back button or using the system's window management. 
> I am talking about the extreme novices here, but this has never been a "power
> users" browser, even though such users tend to adopt it. 
> I maintain the right decision in the absence of a comprehensive set of tabbed
> browsing discovery tools is to not force the feature on people. 

There is a simple solution to the issue of novices having problems with 
external apps opening into a new tab rather than a new window, and this 
solution would also provide additional security for the user.  It would seem 
beneficial to have a dialog window pop-up when an external program is trying 
to access the internet through Firefox.  

The dialog would say something to the effect of "Program X is trying to access 
url".  There could then be three options for the user to select 1) Open in new 
window 2) Open in new tab 3) Do Not Allow.  There could also be a checkbox 
with the option "Always perform this action for this program".

This would also help when a particular user has unknowingly installed spyware 
which would try to access the internet via Firefox.

Comment 28

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #27)
> The dialog would say something to the effect of "Program X is trying to access 
> url".  There could then be three options for the user to select 1) Open in new 
> window 2) Open in new tab 3) Do Not Allow.  There could also be a checkbox 
> with the option "Always perform this action for this program".

I'd rather we do nothing than do this. Let's not give the user *another*
whitelist, with yet more things to manage, and instead try and get to a default
behaviour that's representative of what we believe the best browsing experience
to be.

Comment 29

[Ben Goodger (Sorta Watching)]

Comment on attachment 193761 [details] [diff] [review]
patch

marking this obsolete until we crystallize our strategy for 1.5

Comment 30

[Ben Goodger (use ben at mozilla dot org for email)]

minusing to get this off my radar now this is being tracked in 308396. 

Comment 31

[:Gavin Sharp [email: [e-mail]]]

*** Bug 317188 has been marked as a duplicate of this bug. ***

Comment 32

[Steffen Wilberg]

This has been fixed by bug 308396, so duping to that.
Check out recent trunk builds: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/

Please file follow-up bugs as appropriate.

*** This bug has been marked as a duplicate of 308396 ***

Comment 33

[mmortal03]

The feature that was implemented by this bug report now looks to have regressed recently.  Since this bug report was marked as a duplicate of the MUCH broader Bug 308396, it seems appropriate to open this back up, instead.  This bug report contains all the proper discussion of the feature in question, and does a much better job at describing what needs to be gotten working again, than starting a fresh bug report.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9.1a1pre) Gecko/2008071903 Minefield/3.1a1pre ID:2008071903

Comment 34

[:Gavin Sharp [email: [e-mail]]]

No.

Please file new bugs on new issues. Reopening bugs resolved more than two years ago is never the right thing to do.

Comment 35

[mmortal03]

I've reverted all changes that I've made here, and am opening a new bug report, instead, then. I will link to this one in it, suggesting it to anyone who needs further details.