Closed Bug 131037 Opened 22 years ago Closed 22 years ago

Close Tab Behavior Should Be A Pref with UI

Categories

(SeaMonkey :: Tabbed Browser, enhancement)

Product:
SeaMonkey
Component:
Tabbed Browser
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED WONTFIX

People

(Reporter: mrmazda, Assigned: jag+mozilla)

References

Details

Attachments

(1 file)

Screenshot
8.52 KB, image/png
Details 
Based upon discussion in bug 105722 and elsewhere, prefs should contain the
following options:

[ ] After closing a tab, focus the left most tab
[ ] After closing a tab, focus the right most tab
[ ] After closing a tab, focus the tab to the left of the closed tab
[ ] After closing a tab, focus the most recently focused tab
[X] After closing a tab, focus the tab from which closed tab was originally opened
following options:

[X] After closing a tab, focus the left most tab
[X] After closing a tab, focus the right most tab
[X] After closing a tab, focus the tab to the left of the closed tab
[X] After closing a tab, focus the most recently focused tab
[X] After closing a tab, focus the tab from which closed tab was originally 
opened

brilliant. please think this through and spam a newsgroup for at least two 
weeks before posting another bug or comment for this stuff.
How could you possibly check all five at once? You'd have to choose only one.
A checkbox is never mutually exclusive.

(*) This ( ) Readio ( ) Button ( ) Set ( ) is ( ) mutually ( ) exclusive.
Open prefs and go to:

     debug -> networking -> directory listing format

This is the appropriate behavior: radio buttons, not checkboxen. Selecting one
automatically unchecks the previous choice. Mutually exclusive choices. One of
the selections can be valid at once, not any or all as with checkboxen in:
navigator -> select the buttons you want to see in the toolbars.

I think the point was that your ascii art showed checkboxes, not radio buttons.

Confirming rfe, and putting in a vote for "wontfix because this will make the
prefs UI even more cluttered".
Status: UNCONFIRMED → NEW
Ever confirmed: true
I can't recall seeing an ASCII art means to distinguish radio buttons from
checkboxen.

In 2002042409 OS/2 trunk I see a grand total of four checkboxes on a nearly
empty tabbed browser prefs sheet. I can't picture adding this causing "clutter".

Tabbed browser is currently one of the best browser features ever, but that
means improving it is unnecessary or undesirable. On the contrary. Causing prefs
"clutter", even if it really were to do so, should be no impediment to this
improvement.

> I can't picture adding this [UI/pref] causing "clutter".
Agreed (current behavour is less useful) -> Vote added :-P

New ASCII art for those who didn't unserstand the obvious:

+- Tabs Closing Behavour ---------------------------------------+
|                                                               |
| When closing a tab, do the following:                         |
| (o) focus the most recently focused tab                       | <- default
| ( ) focus the tab from which closed tab was originally opened |
| ( ) focus the tab to the left of the closed tab               |
| ( ) focus the tab to the right of the closed tab              |
| ( ) focus the left most tab                                   |
| ( ) focus the right most tab                                  |
+---------------------------------------------------------------+

If we must save space, it could be done as a dropdown list (I don't prefer this
solution).

 When closing a tab, do the following:
   _______________________________________________________________
  [ focus the most recently focused tab                       |\/|
  |--------------------------------------------------------------|_
   |focus the tab from which closed tab was originally opened     |
   |focus the tab to the left of the closed tab                   |
   |focus the tab to the right of the closed tab                  |
   |focus the left most tab                                       |
   |focus the right most tab                                      |
   +--------------------------------------------------------------+
Please add

 ( ) After closing a tab, focus the tab to the right of the closed tab

This behavior is usefull for pages of links, like Slashdot.
I have been asked to vote for this bug. After reding through the comments of the
bugs that relate to that one, I think the way mozilla currently behaves is the
Right Way. Although, the fact that there is no way to make that "Just Work" for
everyone, adding a preference to the preferences dialog doesn't buy anyone
anything, because firstly, the preferences dialog already is far too crowded and
not-easily-graspable by the casual, normal user. Secondly, different situations
require different approaches to that problem. You don't want to change some
preference everytime you want to do something different (that works best with
some other close-tabs-behaviour).

Therefore I suggest RESOLVED WONTFIX. 

"the preferences dialog already is far too crowded and not-easily-graspable by
the casual, normal user"

This is absurd. Each prefs tab stands on its own. Currently the tabbed browser
tab is among the most sparsely populated, containing a mere 4 check boxes, each
with a short, half line description.

"You don't want to change some preference everytime you want to do something
different"

Maybe you don't want to. Others find the ability to change behavior according to
their needs is precisely the reason to choose one product over another, e.g.
Mozilla on a system that has IE.
"I think the way mozilla currently behaves is the Right Way."

That's all well and good, but it is abundantly obvious from the discussion in 
previous bugs that not everyone, heck, not even a majority of other users agree 
with you. If you like the way Mozilla currently behaves, feel free to leave the 
pref on the default setting, but don't begrudge everyone else the choice. This 
is what prefs are *for* - preferences.
This is getting insane.

1. No one needs these:

| ( ) focus the left most tab                                   |
| ( ) focus the right most tab                                  |

2. This is still too many options:

| When closing a tab, do the following:                         |
| (o) focus the most recently focused tab                       | <- default

This makes most sense to me.

| ( ) focus the tab from which closed tab was originally opened |

This might sound good, but seems confusing to me.

| ( ) focus the tab to the left of the closed tab               |

This is current behaviour, right? Then this should be an option.

| ( ) focus the tab to the right of the closed tab              |

This is useful for news sites. That leaves us with:

| When closing a tab, do the following:                         |
| (o) focus the most recently focused tab                       | <- default
| ( ) focus the tab from which closed tab was originally opened | <- eventually
| ( ) focus the tab to the left of the closed tab               | <- classic bhvr
| ( ) focus the tab to the right of the closed tab              |

Now, put them in a dropdown and there we have it.
Can someone explain to me when any option is useful besides, "focus the tab to
the right of the closed tab"?  I honestly can't imagine wanting any other behavior.
#13
First of all, please think of a more "creative" name than "6e77a 70 6e 6e7a".

> Can someone explain to me when any option is useful besides, "focus the tab to
> the right of the closed tab"?  I honestly can't imagine wanting any other
> behavior.

| (o) focus the most recently focused tab

I go to a page [A] with many links. I middle-click a link - it opens up as new
tab [page B] in foreground. I read the stuff in that new tab [page B]. I close
it again and would like to return to where I was previously [page A].

| ( ) focus the tab from which closed tab was originally opened

Same as above, except: I go to [page A], open some links on it [B to D], then
open [page Z], read through it. Now I'd like to read [B to D]. After having
finished reading them, I'd like to return to [A].

| ( ) focus the tab to the left of the closed tab

Well... umm... we're used to that, that's it ;-)

| ( ) focus the tab to the right of the closed tab

You already know why.
The following two options are useful for going back to a search query, which is
usualy the "left most" tab:

( ) focus the left most tab
( ) focus the tab from which closed tab was originally opened

Either one would suffice, but please don't eliminate both.
#16
Funny, I saw that comment few minutes before my comment #12 in this thread :-)
It's exactly my opinion. We're cluttering / overloading the preferences with
"0.00001% of the people out there *might* one day prefer this way" settings.
I'd be happy with just some way to change the behavior in the pref.js file.  I
don't need no stinkin' GUI! :-)

'First of all, please think of a more "creative" name than "6e77a 70 6e 6e7a".'
Um, why?
#18
> I'd be happy with just some way to change the behavior in the pref.js file.
> I don't need no stinkin' GUI! :-)

And we don't need no stinking code nobody will ever profit from. So no to
prefs.js additions also :-P

---

With the risk of getting accused at spamming bugzilla, I'll answer the other
one, too:

> 'First of all, please think of a more "creative" name than "6e77a 70 6e 6e7a".'
> Um, why?

Possibly because I don't happen to be good at remembering names that do not make
sense at all? And I would prefer to *know* who I'm talking to / who I'm
referring to / who made this and that comment?
"6e77a 70 6e 6e7a" => betta to be beta ?
"Democracy is two wolves and a lamb voting on what to have
for lunch.  Liberty is a well-armed lamb contesting the vote."
						Benjamin Franklin

Prefs are there to allow inequals to happily coexist.

Many people are inclined to experiment with UI prefs who would never consider
mucking in prefs.js or user.js, much less be able to figure out where to go to
find out what all the stuff in there means, or how and whether a desired change
in behavior might be possible. Some don't because they don't want to disrupt
their open windows/tabs/history by having to close the Mozilla to edit the .js
file, then restart. Unless a particular behavior truly would be used by a very
very small number of users, a pref should have a UI for it. Otherwise, an
otherwise great feature is un- or under- utilized.

I doubt out of the total population of those who actually use tabbed browsing
that there wouldn't a be substantial proportion who would disagree on which
should be the default, much less on which should be the exclusive behavior given
the possibilities presented. The comments here so far pretty much demonstrate this.

Maybe everyone won't be using tabbed browsing. That's their tremendous loss, not
a reason to make Mozilla less that it can be. From this discussion it is quite
obvious that there are different strokes for different folks, which is precisely
the definition of a need for adjustment via preferences.

I filed the bug, and I put the X in the last box for a reason. If I can't have a
choice, then maximum usability behavior for me is normally to shift focus to
whichever tab spawned the closed tab. I keep Mozilla open 24/7, and typically
have at least five tabs open at once when doing anything important, usually
quite a bit more than that. Since I have many things going on at once, commonly
spanning a long period of time, there is no way to remember every which spawned
which in order to get back there manually after a tab close. Other subjects come
along to interpose. There's no avoiding it unless you don't use the PC or brower
very much, which is precisely why other behaviors make more sense for other
usage patterns, and why a pref is needed.

Occasionally, I would find last focused to be more useful, but only if I could
quickly change to it from parent spawning it. Again, only if there is a UI could
I, or anyone else, do this.


#20
Yes, okay... umm... do we really need 1337 in here?

#21
> Prefs are there to allow inequals to happily coexist.

Indeed. That's why it's called *prefer*ences. As in "[user x] prefers [pref a]
and [user y] prefers [pref b]".

> Maybe everyone won't be using tabbed browsing.

I know of at least one person quite active in Mozilla's development who *hates*
tabbed browsing. That's why there are prefs to deactivate it completely.

The problem is simply that we have so many options already. Just look at the
mouse wheel panel - there's literally no one on earth who would really benefit
from its ability to explicitly define each mouse wheel behaviour.

That's why I was suggesting less options than in your original description.
The current tabbed browser prefs page has a grand total of four lines with
checkboxen, three title lines, and the standard bottom row of buttons. It has
more vertical whitespace than consumed vertical space. "So many options already"
is not something that currently applies to tabbed browsing prefs.

Personally, of the five I originally listed, I would use only the last two. The
others are there to please others. Each should stand on its own merit. Any one
that doesn't merit being there should go, but I don't think any of the five have
failed the merit test so far.
I propose we WONTFIX this because there is already a good workaround: use
multiple windows to group related tabs.  It doesn't address all of the
complaints here, but I think that if we actually implemented this, people would
find it less useful than they think: some options are only useful for news
sites, others for search.  If we go down this route, we're going to have people
asking to be able to specify the behaviour on a per-domain basis ... 
Workaround, yes. Good, no. I want one browser, always in the same place. Tabs
are the solution for people who don't want a zillion browser windows scattered
all over. A per domain basis would be a separate bug to be considered on its own
merits.
No It Should Not.

And before _anyone_ starts complaining at me that it's Not Fair that I am
Ignoring The Popular Vote and that we Must Accept this feature or At Least Have
A Pref To Show The Pref, no. The module owner has vested in me the power to
WONTFIX tabbed browser bugs and in that position I am declaring that We Shall
Not Have A Pref For The Tab Behaviour.

WONTFIX.

The only person who is allowed to reopen this is the module owner himself.
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → WONTFIX
Current behavior sucks.

You seem to be new here Mr Tyrant. Where was your participation in the
discussion? What's the rush to wontfix? Seems to me there's room to let this lie
a while (future) for more discussion and feedback from release users. Leave this
closed/wontfix and others will open dupes. The current behavior makes it inevitable.
Status: RESOLVED → REOPENED
Resolution: WONTFIX → ---
The current behaviour may well suck. However, _this_ bug didn't ask for a change
to the behaviour, it asked for a new pref. If you want a change to the behaviour
please file a bug asking for that.


> You seem to be new here Mr Tyrant.

I assume by "here" you mean this bug. Indeed, I had not seen this bug before. I
am unsure how I missed it.


> Where was your participation in the discussion?

Comment 26.


> What's the rush to wontfix?

The rush is that it is misleading to leave a bug open when there is no intention
to accept a patch if one was written.


> Seems to me there's room to let this lie a while (future) for more discussion 
> and feedback from release users.

Feedback from release users should go in newsgroups, not Bugzilla. Bugzilla
represents the intention of the module owner. The module owner has no intention
of ever fixing this bug nor of accepting a patch to add prefs as requested by
this bug. Therefore WONTFIX is the appropriate resolution.

Only the module owner has the right to reopen this bug, indicating that he has
changed his opinion.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 22 years ago
Resolution: --- → WONTFIX
Verified.
Status: RESOLVED → VERIFIED
This bug asked implicitly for a change in behavior. Bug 144154 filed to
explicitly make the same request.

Keyword in comment 27 was "was". ian@hixie.ch participated zero prior to
ian@hixie.ch edict.

If the module owner wants to be a tyrant, he should do it himself, not delegate.
It would be nice if he also would be less tyrannical and actually participate in
the discussion and elucidate valid reasons for his position.

The reason why not is that we have too many prefs already. Thus there is a
general Mozilla-wide focus on reducing our pref count. Too many prefs makes us
intimidating to users.
Attached image Screenshot — 
Too many prefs? Surely you jest. This screen is nearly a desert.

Where is/has the "reducing our pref count" discussion taking/taken place?
*** Bug 144154 has been marked as a duplicate of this bug. ***
[For the record: Bug 144154 was maliciously filed by the same person who filed
this bug, so in no way does it support the claim that `others will open dupes'.]
> we have too many prefs already...

I strongly disagree. Nevertheless, this misconception and the importance of
satisfying user's requests for control over Mozilla's behaviour further
demontrates the need to fix bug ??? ("need *advanced* preferences").
> Too many prefs? Surely you jest. This screen is nearly a desert.

That screen shouldn't even exist, it should be merged with one of the two or
three dozen other pref panels.


> Where is/has the "reducing our pref count" discussion taking/taken place?

To give but a few examples: http://mpt.phrasewise.com/discuss/msgReader$207, 
http://ln.hixie.ch/?start=1021130439&count=1, irc://irc.mozilla.org/mozilla,
http://www.blakeross.com/archives/2002_05_12_index.html#76476722
I went to the three http examples and found virtually none of what I asked for.
There was no discussion there, merely diatribes from three people I can't be
sure weren't one and the same. I spotted no provision to see parent or follow-up
discussion. Why were no Mozilla newsgroup or mailing list references cited?

Sounds like ian@hixie.ch's primary interest is in bailing (getting Mozilla over
with ASAP in order to find pursue other interest), rather than making Mozilla
the best humans can make it.

Cutting away potential usability improvements via proclaiming "too many prefs"
is unwarranted. Just because people have the power to be tyranical doesn't mean
they should exercise it, and it certainly is not a good thing in the grand
scheme, whether exercised by groups or individuals.

This bug is everything but complete. You failed to include the option I want to
have in the new prefs:

( ) After closing a tab, close all other tabs
      ( ) except the one to be closed
      ( ) and exit application
               [ ] and launch notepad/vim instead
(o) After closing a tab, focus a random tab
( ) After closing a tab, reopen it
( ) Any of the above

But of course this can't be implemented until I can set how exactly I want to
close a tab. That problem is covered in Bug 108941 and should be considered a
blocker to this bug.

This bug is, of course, _the_ only bug which prevents me from migrating from
Netscape 4.? to Mozilla. So it should be fixed yesterday.
>Occasionally, I would find last focused to be more useful, but only if I
>could quickly change to it from parent spawning it. Again, only if there
>is a UI could I, or anyone else, do this.

To change the behavior quickly - those options should be in a menu, too. Preferably
&View -> &Tabclosingorder
#37
> I went to the three http examples and found virtually none of what I asked for.
> There was no discussion there,

Obviously not. They are blogs. Blogs (short for "weblogs", quite similar to "web
diaries") are usually written by a single person.

> merely diatribes from three people I can't be sure weren't one and the same.

I can tell you they're absolutely different persons. And they couldn't live much
further away from each other either (Oceania, Europe, America).

> I spotted no provision to see parent or follow-up discussion. Why were no
> Mozilla newsgroup or mailing list references cited?

The mailing lists are mirrors of the newsgroups. And there is no newsgroup
thread about this. Feel free to start one, but most newsgroup threads
unfortunately end up in "my opinion counts; yours doesn't".

hixie also pointed to the #mozilla IRC channel, where the actual discussion took
/ takes place.

> Sounds like ian@hixie.ch's primary interest is in bailing (getting Mozilla over
> with ASAP in order to find pursue other interest), rather than making Mozilla
> the best humans can make it.

Troll. No really... I mean, you could as well have left that sentence / that
whole paragraph away.

> Cutting away potential usability improvements via proclaiming "too many prefs"
> is unwarranted.

The consensus is that too many prefs only cause harm.

> [blah]
Markus, if all you have to cotribute is sarcasm, then please shut your hole.

> The consensus is that too many prefs only cause harm.

"Consensus" among which unrepresentative group? Regular users (almost) never
even go into prefs, unless they are specifically told where to go and what to
do. You are merely ruining it for those of us (power users) who who are an
*integral part* of this project. Thanks a lot.

BTW. All the newsgroup discussion I have followed (not diatribes by the few
nay-sayers here) showed a *vast* interest in various Tab Closing behaviours -
none being the current nonsensical behaviour.
Too much of anything causes harm. Swatting bugs simply because they involve a
pref rather than on the merits of what they request dodges the broader issue of
how many is too many. The current tab pref page is fine being separate, except
that it offers no option to not have the dopey current behavior.

mpt@mozilla.org.uk needs to look up the definition of malicious.

New bugs have been filed to request both of the last two of five items in the
original prefs proposal as sole behavior substitutes for the current behavior,
144207 & 144208.

>Markus, if all you have to cotribute is sarcasm, then please shut your hole.
I thought my contribution and opinion was clear: WONTFIX this and your new bugs.

>none being the current nonsensical behaviour.
"Currently, when a tab is closed, focus shifts to the tab to the left of the
position occupied by the closed tab."
Seems logical to me. You open the tabs from left to right, you close them from
the right to the left.
The reason I voted for this bug:  The current behavior
is great, _if_ you always open new links from the rightmost
tab.  However, if you, say, keep slashdot open on one of
your tabs, and then return to it after opening other
windows, then you get this weird behavior:
Read slashdot, open link.  Close link, and .. you're
back to the Yahoo page, not the slashdot page.

This whole discussion has gotten ridiculous.  This is a simple
feature addition that won't add much clutter to the UI, is
already well-supported in Opera, and doesn't add much code.
The very fact that there are so many people who've 
independently submitted this feature request should suggest
that it's a very valid option.
"The reason I voted for this bug:  The current behavior
is great, _if_ you always open new links from the rightmost
tab."

I got excited when I read this, but I must have misunderstood you.  I was hoping
that if I opened up Slashdot in the rightmost tab it would work differently.

Your Slashdot scenario is right on.  This is how I use Google too.  I open
Google and start control-clicking the links I think are useful, then I view them
from oldest to newest.  In my opinion, changing focus to the right after closing
a window seems a reasonable default behavior.  I haven't heard anyone defend the
current behavior.

Is there some way to remap a key (like control-w) to close the current window
and then do a control-pgdn to move to the right?  I'll bet it's possible, but I
don't know how to do it.  With a work-around we don't need the help of the code
Nazi.
> Is there some way to remap a key (like control-w) to close the current window
> and then do a control-pgdn to move to the right?

Control-F4 closes current tab. Control-PgDn goes to next one.
*** Bug 152932 has been marked as a duplicate of this bug. ***
*** Bug 157936 has been marked as a duplicate of this bug. ***
*** Bug 121477 has been marked as a duplicate of this bug. ***
*** Bug 162672 has been marked as a duplicate of this bug. ***
*** Bug 279733 has been marked as a duplicate of this bug. ***
K-Meleon, Crazy Browser (an excellent shell for IE), the evil/unlisted
Tabbrowser Extensions all offer this feature. Except for Firefox which boasts
tabbed browsing as one of its advantages. There is enough "irony" in this fact
to summon a wide smile on my face :-)
Product: Core → SeaMonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: