Closed Bug 131037 Opened 23 years ago Closed 23 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: 23 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: 23 years ago → 23 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: