Open Bug 534221 Opened 15 years ago Updated 4 years ago

Implement close (x) button on every tab (browser.tabs.closeButtons)

Categories

(SeaMonkey :: Tabbed Browser, enhancement)

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

Tracking

(Not tracked)

Status:
ASSIGNED

People

(Reporter: Milos, Assigned: philip.chee)

References

Details

(Whiteboard: [SeaMonkeyTestday])

Attachments

(2 files, 1 obsolete file)

screenshot
177.59 KB, image/png
Details
Patch v1.2 Firefox style tab close buttons.
34.78 KB, patch
neil
: review-
Details | Diff | Splinter Review
Implement close (x) button on every tab, just like on Firefox.
Whiteboard: [SeaMonkey Testday]
Whiteboard: [SeaMonkey Testday] → [SeaMonkeyTestday]
Workaround: <http://www.tom-cat.com/mozilla/seamonkey/extensions-seatabx.html>
Summary: Implement close (x) button on every tab → Implement close (x) button on every tab (browser.tabs.closeButtons)
I trust this stupidity will either have UI to change the pref, or be off by default, or both.
Attached image screenshot —
SM was not specially set up for a screenshot for this bug. The last opened tab was opened some time before I went to bed last night, point being there's easily/often no room for icons of any kind in my normal use. The first thing I do in every new FF profile is open about:config to move the close button off the tabs.
Another vote AGAINST this RFE. Having the close tab button on each tab is one of the worst usability issues with Firefox. The user actually needs to "chase" the button every time a tab is closed. With SM, just keep the cursor on the same spot and click click click to close tabs. Way better. Prog.
Just let those who want it have it. I mean, there is a setting for it and SM2 does not respect it. This request is just to fix that, then anyone is free to configure it as they wish.
> then anyone is free to configure it as they wish. Right. Even if we implement this, the default would still be no close buttons on the tabs.
I dislike those close buttons to. But why do we have these little green flags on every tab if screen space is scarce?
Taking bug.
Assignee: nobody → philip.chee
Status: NEW → ASSIGNED
Currrently Firefox does this: browser.tabs.closeButtons: // Where to show tab close buttons: // 0 on active tab only // 1 on all tabs until tabClipWidth is reached, then active tab only // 2 no close buttons at all // 3 at the end of the tabstrip pref("browser.tabs.closeButtons", 1); There are several problems with this design: 1. The close button takes up some of the real estate on each tab that has one. Because of this limitation the all-tabs mode only works until a pref controlled tab width (tabClipWidth) is reached. When there are too many (small) tabs only the active tab gets a close button to prevent the number of visible tabs getting reduced. An inconsistent UI is bad design. 2. Every time a tab is added, or removed, or the UI is resized the tabwidth has to be recalculated and compared against the pref setting. I'm sure that this has at least some Tx perf regression. 3. The |browser.tabs.closeButtons| isn't a set of boolean flags which means that you can't control the visibility of the tabstrip close button independently of the close buttons on the tabs. Proposed design: Implement Multizilla style close button on hovered tab. This overloads the tab favicon so that when the tab is hovered over with the mouse the favicon changes into a close tab button. Advantages: 1. No extra real estate is needed for the close buttons on the tabs. 2. No need to recalculate the tabwidth every time the UI changes. (So we don't need the tabClipWidth pref either). 3. We can (optionally) do away with modes 1 (all tabs) and 2 (active tab) and have only one mode, hovered-tab. 4. Reduced complexity in the bindings and code needed improving the maintainability. Preferences design: Use a prefence name that is not the same as the Firefox preference since our behaviour is different. 1. First Proposal: A set of boolean flags. browser.tabs.closeButton 001 == at the end of the tabstrip. 01base10 010 == on the active tab. 02base10 100 == on non-active tabs. 04base10 Or just: 001 == at the end of the tabstrip. 01base10 010 == close button on all (hovered) tab. 02base10 Default would be 0x01 which is the current behaviour of having one close button at the end of the tabstrip. 1. Second Proposal: Two of separate flags. browser.tabs.closeButton.tabStrip (boolean) browser.tabs.closeButton.allTabs (boolean) i.e. visible only on the hovered tab.
(In reply to comment #14) > Proposed design: > > Implement Multizilla style close button on hovered tab. This overloads the tab > favicon so that when the tab is hovered over with the mouse the favicon changes > into a close tab button. > > Advantages: > > 1. No extra real estate is needed for the close buttons on the tabs. > 2. No need to recalculate the tabwidth every time the UI changes. (So we don't > need the tabClipWidth pref either). > 3. We can (optionally) do away with modes 1 (all tabs) and 2 (active tab) and > have only one mode, hovered-tab. > 4. Reduced complexity in the bindings and code needed improving the > maintainability. Safari also displays the close button only, if the user hovers over the tab label, so users might be already familiar with this GUI design.
Asking for initial review of working patch.
Attachment #421067 - Flags: review?(neil)
Comment on attachment 421067 [details] [diff] [review] Patch v1.0 Multizilla style tab close buttons. > // Where to show tab close buttons: > // 0 on active tab only > // 1 on all tabs until tabClipWidth is reached, then active tab only >-// 2 no close buttons at all >-// 3 at the end of the tabstrip >+// 2 no close buttons at all in mailtabs >+// no close buttons on tabs in tabbrowser >+// 3 at the end of the tabstrip for mailtabs only >+// has no effect in tabbrowser > pref("browser.tabs.closeButtons", 3); >+pref("browser.tabs.closeButtons.tabstrip", true); This is IMHO way too confusing, and any difference in display between tabbrowser and tabmail is not really acceptable in my eyes as well - if we change anything, then let's unify the behavior. Also, IMHO, the worst two ideas one could have is close buttons not visible when the focus is not on the right place and two close buttons for the same tab visible at the same time. IIUC, you proposed both of those, so I can't really accept this.
> Also, IMHO, the worst two ideas one could have is close buttons not visible > when the focus is not on the right place and two close buttons for the same tab > visible at the same time. IIUC, you proposed both of those, so I can't really > accept this. I didn't say that either of these would be the default. The current UI would not certainly not change. However these options would be available for users if they want these. FYI in the mozillazine firefox support forums there have been requests from users for information on how to turn on the tabstrip close button as well as keeping the tabs close buttons.
(In reply to comment #16) > Created an attachment (id=421067) [details] > Patch v1.0 Multizilla style tab close buttons. > > Asking for initial review of working patch. We do need to match browser and mailnews, so this patch should could both. I think the existing preferences should continue doing what they do at the moment and have an option 4 for doing it Multizilla style.
> We do need to match browser and mailnews, so this patch should could both. > I think the existing preferences should continue doing what they do at the > moment and have an option 4 for doing it Multizilla style. I can change mailnews to match the current patch in navigator as well. I disagree with doing it the firefox/mailtabs way at all. The code there is extraordinarily ugly partly because it needs a lot of workarounds due to problems caused by their design. My code is much simpler and less fragile.
(In reply to comment #20) > > We do need to match browser and mailnews, so this patch should could both. > > I think the existing preferences should continue doing what they do at the > > moment and have an option 4 for doing it Multizilla style. > > I can change mailnews to match the current patch in navigator as well. I > disagree with doing it the firefox/mailtabs way at all. The code there is > extraordinarily ugly partly because it needs a lot of workarounds due to > problems caused by their design. My code is much simpler and less fragile. Do we currently take any notice of browser.tabs.closeButtons? I'm sure I have tried them all and it is as if it is still on 3 (restarting between each change). I think if we do have the Multizilla style option then we could still do a simpler, more stable version of the firefox/mailtabs way (then use prefs to control the style too).
(In reply to comment #20) > I disagree with doing it the firefox/mailtabs way at all. And I disagree with not matching their pref and behavior at all.
We should keep in mind that we finally want to merge both tabbrowser widgets into one which can do "everything" what mailtabs and browsertabs can (eg. the actual tab mode implementations à la mailtabs wouldn't be part of such a widget). As such, we should not create incompatibilities in the meantime.
IanN: > Do we currently take any notice of browser.tabs.closeButtons? I'm sure I have > tried them all and it is as if it is still on 3 (restarting between each > change). Mailnews tabs recognize those prefs. > I think if we do have the Multizilla style option then we could still do a > simpler, more stable version of the firefox/mailtabs way (then use prefs to > control the style too). I think I can do that but I might need to clean up the mailtabs code first before starting on a combined patch. KaiRo: >> I disagree with doing it the firefox/mailtabs way at all. > And I disagree with not matching their pref and behavior at all. OK I'll look into matching their pref and behaviour but have multizilla style close buttons in addition. Question: do I create a new pref for multizilla style or extend the values of the existing |browser.tabs.closeButtons|? The problem with the latter is that Firefox might decide later on to add more modes which might be incompatible with what ever values we chose. Or we could reserve 0-15 for firefox changes and then start our suite specific settings from #16 onwards.
(In reply to comment #24) > Question: do I create a new pref for multizilla style or extend the values of > the existing |browser.tabs.closeButtons|? The problem with the latter is that > Firefox might decide later on to add more modes which might be incompatible > with what ever values we chose. Ideally, they would appreciate the code cleanup and enhancements, and the code could be shared.
Hi Ratty, I saw you were talking with Kairo about a UI for your new prefs and were worried about the tabbed browsing pane being full already. Just mooting, but would it making a Tabs entry under Appearance and putting prefs that concern the look of the tabs there (like whether they have a close button), particularly since both browser and main tabs might be affected simultaneously?
oops -> ...would it be worth... ?
oops oops - > ...browser and mail tabs ... Sorry for spam.
I don't think Appearance is a 100% fit since close buttons are functional rather aesthetics. I was thinking of proposing to promote the Tabbed Browsing sub-category to a separate main category (Application Tabs?) and then splitting the existing prefpane into two or more subpanes.
Comment on attachment 421067 [details] [diff] [review] Patch v1.0 Multizilla style tab close buttons. > // Where to show tab close buttons: > // 0 on active tab only > // 1 on all tabs until tabClipWidth is reached, then active tab only >-// 2 no close buttons at all >-// 3 at the end of the tabstrip >+// 2 no close buttons at all in mailtabs >+// no close buttons on tabs in tabbrowser >+// 3 at the end of the tabstrip for mailtabs only >+// has no effect in tabbrowser > pref("browser.tabs.closeButtons", 3); >+pref("browser.tabs.closeButtons.tabstrip", true); Sorry, but I think that the pref values should be synchronised between tabbrowser and tabmail. In particular I can't see why people would want extra close buttons. >+ onmouseover="this.selectedIndex = 1;" >+ onmouseout="this.selectedIndex = 0;" Why the duplication? >+ oncommand="document.getBindingParent(this).doCloseButton(event);"> Not used? >+ case "click": Not used? >diff --git a/suite/themes/classic/navigator/icons/close.png b/suite/themes/classic/navigator/icons/close.png I didn't think to try this out in Classic, but do we really not have enough close icons? >+.tabs-closebutton[disabled="true"] { Ironic that you removed the xbl:inherits for this.
Attachment #421067 - Flags: review?(neil) → review-
> Sorry, but I think that the pref values should be synchronised between > tabbrowser and tabmail. In particular I can't see why people would want extra > close buttons. Fixed. >>+ onmouseover="this.selectedIndex = 1;" >>+ onmouseout="this.selectedIndex = 0;" > Why the duplication? Fixed. >>+ oncommand="document.getBindingParent(this).doCloseButton(event);"> > Not used? Fixed. >>+ case "click": > Not used? Fixed. >>diff --git a/suite/themes/classic/navigator/icons/close.png b/suite/themes/classic/navigator/icons/close.png > I didn't think to try this out in Classic, but do we really not have enough > close icons? Removed. >>+.tabs-closebutton[disabled="true"] { > Ironic that you removed the xbl:inherits for this. Fixed. > -pref("browser.tabs.tabMinWidth", 100); > +pref("browser.tabs.tabMinWidth", 50); > -pref("browser.tabs.tabClipWidth", 140); > +pref("browser.tabs.tabClipWidth", 90); Just guessing at the numbers here. > diff --git a/suite/browser/tabbrowser.xml b/suite/browser/tabbrowser.xml > <!DOCTYPE bindings [ > -<!ENTITY % tabBrowserDTD SYSTEM "chrome://navigator/locale/tabbrowser.dtd" > > -%tabBrowserDTD; > + <!ENTITY % tabBrowserDTD SYSTEM "chrome://navigator/locale/tabbrowser.dtd" > > + %tabBrowserDTD; > + <!ENTITY % globalDTD SYSTEM "chrome://global/locale/global.dtd"> > + %globalDTD; > + <binding id="tabbrowser-tab" > + display="xul:box" > + extends="chrome://global/content/bindings/tabbox.xml#tab"> > + <content chromedir="&locale.dir;"> 1.9.3 doesn't use chromedir so we don't need the global.dtd. If we don't care about 1.9.2 I can remove these. > +++ b/suite/locales/en-US/chrome/browser/tabbrowser.dtd > @@ -1,17 +1,18 @@ > +<!ENTITY closeTab.tooltip "Close tab"> > +++ b/suite/locales/en-US/chrome/mailnews/messenger.dtd > <!-- tabmail --> > -<!ENTITY tabmailClose.tooltip "Close tab"> Moved one entity from messenger.dtd to tabbrowser.dtd. I could possibly move the whole tabmail section to tabbrowser.dtd. > +++ b/suite/mailnews/tabmail.xml > <method name="adjustTabstrip"> > case 1: > - let width = this.firstChild.boxObject.width; > + let width = this.firstChild.getBoundingClientRect().width; Sync with Firefox 3.7a1pre.
Attachment #421067 - Attachment is obsolete: true
Attachment #426833 - Flags: review?(neil)
One problem I haven't been able to solve is that in the Default/Classic theme, the Firefox style tab close toolbarbutton causes the tabs to grow in hight noticeably. Setting -moz-appearance: to none allows me to shrink the in-tab close buttons but of course you lose all the OS styling. Ugh. I just checked Minefield and they *do* use -moz-appearance: none;
Comment on attachment 426833 [details] [diff] [review] Patch v1.2 Firefox style tab close buttons. You forgot to fix the mac tabbrowser.css. Note that the tabs close-button is different on mac (you can probably use that for the tab close button).
Yargh! But I don't have a Mac so I have to do this blind again?!? Grrr.
Just use the same image as I'm using for the tabs close-button. The mac browser tabs doesn't use any -moz-appearance, so there shouldn't be any oddities.
Comment on attachment 426833 [details] [diff] [review] Patch v1.2 Firefox style tab close buttons. >-pref("browser.tabs.tabMinWidth", 100); >+pref("browser.tabs.tabMinWidth", 50); > pref("browser.tabs.tabMaxWidth", 250); >-pref("browser.tabs.tabClipWidth", 140); >+pref("browser.tabs.tabClipWidth", 90); [Why these changes?] >+.tabbrowser-tabs[closebuttons="activetab"][closetype="deck"] >+ > .tabbrowser-tab[selected="true"] { >+ -moz-binding: url("chrome://navigator/content/tabbrowser.xml#multizilla-tab"); >+} When does this happen? >+ this.mTabContainer.adjustTabstrip(); This only makes a difference in the active tab case, right? >+ t.setAttribute("maxwidth", this.mTabContainer.mTabMaxWidth); >+ t.setAttribute("minwidth", this.mTabContainer.mTabMinWidth); These aren't dynamic preferences, and we can't actually guarantee binding construction order, so it may be better to just look them up here. >+ this.mPrefs.addObserver("browser.tabs.", this, false); You're only really interested in two prefs. If you made one a child of the other, this would allow you to limit the scope of the observer. >+ this.mTabstripClosebutton.collapsed = this.mCloseButtons != 3; Can't you achieve this effect via CSS? >+ if (aTopic != "nsPref:changed" || !aData) Nit: you're going to switch on aData anyway. >+ case kCloseButtons: >+ this.mCloseButtons = this.mPrefs.getIntPref(kCloseButtons); Nit: could use getIntPref(aData) and inline the string literals. >+ this.adjustTabstrip(); [This gets called for any prefs, not just the two you want. Less of a problem if you fix the pref names as above though.] >+ tabindex="-1" Where does this come from? >+ onmousedown="event.stopPropagation();" >+ onmouseup="document.getBindingParent(this).doCloseButton(event);" >+ onclick="document.getBindingParent(this).doCloseButton(event);"/> What's the point of all this? Why doesn't onclick="...removeTab..." work? >+ <property name="mTabbrowser"> Nit: only used once. Also, should be equivalent to document.getBindingParent(this.parentNode) >diff --git a/suite/locales/en-US/chrome/browser/tabbrowser.dtd b/suite/locales/en-US/chrome/browser/tabbrowser.dtd What actually changed here? > <!ENTITY closeTabButton.tooltip "Close current tab"> >-<!ENTITY newTabButton.tooltip "Open a new tab"> Nit: closeTab.tooltip belongs somewhere here. Also don't reindent everything. >+ if (this.mCloseBtnType == 1) >+ this.setAttribute("closetype", "deck"); >+ else >+ this.removeAttribute("closetype"); [Need to get some inheritance going at some point to avoid duplicating code. Especially as the first time around there was trailing whitespace!] >+ background: -moz-radial-gradient(45px 45px, ellipse farthest-corner, aqua 0%, rgba(0, 0, 255, 0) 100%, blue 95%); Doesn't this belong in the mac tabbrowser.css?
Comment on attachment 426833 [details] [diff] [review] Patch v1.2 Firefox style tab close buttons. >-pref("browser.tabs.tabMinWidth", 100); >+pref("browser.tabs.tabMinWidth", 50); Presumably this is a compromise between tabmail (which has scrollable tabs) and tabbrowser (which does not)? >+ this.mPrefs.addObserver("browser.tabs.", this, false); This didn't seem to work. At least, I was unable to see any effect other than a debug exception in the system console. Probably a typo somewhere. >+ <xul:toolbarbutton anonid="close-button" >+ tooltiptext="&closeTab.tooltip;" >+ tabindex="-1" >+ class="tabs-closebutton tab-close-button" >+ onmousedown="event.stopPropagation();" >+ onmouseup="document.getBindingParent(this).doCloseButton(event);" >+ onclick="document.getBindingParent(this).doCloseButton(event);"/> This doesn't seem to work very well when the preferences are set to display only on the active tab; if you're unlucky then when you click to switch tab you hit where the close button ends up, thus closing the tab. > .tabs-closebutton { >- margin: 3px; >+ margin: 0px; Nit: 0px is the default margin anyway. >+ padding: 0px; Sorry, I don't like this, it makes the button look odd. (You might be able to get away with 1px padding though if you move the toolbarbutton-icon rule to communicator/button.css [not sure why it doesn't work here].) > .tabs-closebutton { >- margin: 0px 4px; >- padding: 3px 2px; >+ -moz-margin-end: 6px; >+ padding: 0px; This is definitely wrong; the tabs now butt up against the closebutton. (I didn't think to try it with not overriding the margin or padding instead.)
Attachment #426833 - Flags: review?(neil) → review-
Comment on attachment 426833 [details] [diff] [review] Patch v1.2 Firefox style tab close buttons. >+ <binding id="multizilla-tab" Ugh. Can we give that a neutral name that doesn't mention an extension "brand", please?
> Ugh. Can we give that a neutral name that doesn't mention an extension "brand", > please? It's just a WIP. Suggestions?
(In reply to comment #39) > > Ugh. Can we give that a neutral name that doesn't mention an extension "brand", > > please? > It's just a WIP. Suggestions? Maybe "tabbrowser-icon-tab" (with emphasis on "icon", since it's multi-state there)? Maybe "tabbrowser-tab" should be changed, too, but I don't know whether that would have an effect on compatibility (either backwards or with FF). > +// The type of in-tab close button: > +// 0 Like Firefox. A close button at the end of the tab. > +// 1 Like Multizilla. The tab-icon changes to a close button when the tab > +// is hovered over. > +pref("browser.tabs.closeButtons.tabtype", 0); AFAICS this pref is not used. Typo (as in changed your mind, oversight)? BTW: It's MultiZilla. ;-)
(In reply to comment #39) > > Ugh. Can we give that a neutral name that doesn't mention an extension "brand", > > please? > It's just a WIP. Suggestions? Should be descriptive of what it actually is doing compared to the other implementations. What would that be for this binding? > > +// The type of in-tab close button: > > +// 0 Like Firefox. A close button at the end of the tab. > > +// 1 Like Multizilla. The tab-icon changes to a close button when the tab > > +// is hovered over. > > +pref("browser.tabs.closeButtons.tabtype", 0); I would not name either Firefox nor MultZilla here, just tell what we are actually seeing, the explanations are actually good.
This is currently being discussed in the mozilla.support.seamonkey newsgroup (original message at <news://news.mozilla.org:119/0Oydnarf_6knDKbMnZ2dnUVZ_q-dnZ2d@mozilla.org>). As I noted there, I prefer the current capability. It means that the tab whose page I see is the tab that will be closed. It also means that, when I select the X button on the far right, I am unlikely to select a tab adjacent to the current tab by having my cursor positioned incorrectly. Such mispositioning of my cursor becomes more likely as more tabs are opened, which causes each tab to become more narrow. If this change is implemented, therefore, I request that there be a user option to keep the current X button at the far right of the tab bar.
I think this bug has been heading down the wrong track. The pref we already expose, browser.tabs.closeButtons, provides pretty good tab closebutton customizability. We should just honour that pref. It would also make it easier for Firefox switchers as the behaviour would be the same. I wouldn't make the patch to resolve this bug do anything more than honour that pref. A separate bug can be created if necessary to add this config to the prefs UI, though we might not want to bother doing that - we'll be defaulting browser.tabs.closeButtons to 3 anyway to default to the current functionality.
FYI. > browser.tabs.closeButtons value is stored in mCloseButtons. > http://mxr.mozilla.org/comm-central/source/suite/mailnews/tabmail.xml#1052 > mCloseButtons is refered at: > http://mxr.mozilla.org/comm-central/search?string=mCloseButtons&find=&findi=&filter=^[^\0]*%24&hitlimit=&tree=comm-central mCloseButtons(==browser.tabs.closeButtons) is processed as we expect. And, in SeaMonkey 2.19 on Win, browser.tabs.closeButtons=1 worked as expected, but it was in MailNews only. Problem is: Browser code doesn't pay attention to browser.tabs.closeButtons value. Broweser code perhaps doesn't have UI definition for "close button on each tab". Current behaviour of Browser is same as browser.tabs.closeButtons=3. This is never done by default=3. This is done by "ignoring browser.tabs.closeButtons".
OK, I just noticed bug #865826. Firefox devs are going their usual way of removing built-in functionality and telling people to install addons to get it back. I think that pref had been a useful pref, and this is an example of where SeaMonkey can and should provide more useful built-in functionality for users. We should maintain browser.tabs.closeButtons even if Firefox is removing it.
(In reply to Jeremy Morton from comment #47) > OK, I just noticed bug #865826. Firefox devs are going their usual way of > removing built-in functionality and telling people to install addons to get > it back. > > I think that pref had been a useful pref, and this is an example of where > SeaMonkey can and should provide more useful built-in functionality for > users. We should maintain browser.tabs.closeButtons even if Firefox is > removing it. Almost all the changes made by that bug are in files under browser/ — doesn't that mean they are Firefox-only (and that we have forked copies somewhere in suite/)? There are two small exceptions, concerning two CSS style sheets in the toolkit/ tree at the very end of the diff. I agree that this pref is useful (including the comments in the source, which the "Config Descriptions" extensions can get in order to add them in about:config). About the high-handedness of the Firefox guys, sigh, enough has ben said about that since, when was it? Deer Park (Firefox 1.5), I think, when there was a hue and cry in mozilla.support.firefox and/or mozilla.dev.apps.firefox about the disappearance of the throbber link (which we still have, BTW, as no fewer than five prefs named *.throbber.url, and the buttons that go with them).
(In reply to Tony Mechelynck [:tonymec] from comment #48) > Almost all the changes made by that bug are in files under browser/ — > doesn't that mean they are Firefox-only (and that we have forked copies > somewhere in suite/)? There are two small exceptions, concerning two CSS > style sheets in the toolkit/ tree at the very end of the diff. Everything in browser/ shouldn't affect suite/, but the toolkit/ changes do unless there are respective forks in suite/themes/{classic,modern}. On the other hand, this looks trivial.
FWIW, use of browser.tabs.closeButtons by add-ons is now flagged as a "compatibility warning" (see bug 1033705). As long as it is "only" a warning, I suppose it shouldn't worry us overmuch, yet we should be aware of it.
The way Thunderbird handles tab closures is currently being discussed in the mozilla.support.thunderbird newsgroup, in the thread starting with <news://news.mozilla.org:119/mailman.2155.1436567436.14172.support-thunderbird@lists.mozilla.org> (Subject: "How can I add a static tab close button (like we can with Firefox)?") There, the desire is expressed to have tab closures -- the X -- to be the same way currently seen in SeaMonkey. Interestingly, the discussion there indicates Firefox still has at least an option to do it the way SeaMonkey does it. Question for those who advocate in favor of this RFE: Have you never accidentally selected the wrong tab, the tab immediately to the left of the one you really wanted to select? With this change, you would close that adjacent tab instead of viewing the tab you wanted. This is why any implementation should include the option to keep the current X at the far right of the tab bar.
Leave the SM behaviour as it is not and WONTFIX this bug. Firefox has removed the pref, so the alternatives are basically to keep the current behaviour or copy Firefox's behaviour (close button per tab), which many of us dislike. If anyone wants a close button per tab, let them write or download an addon to implement it.
(In reply to Jeremy Morton from comment #53) > Leave the SM behaviour as it is not * as it is now
The items within the right click menu for the tabs bar should be prioritized according to likely safe usage. For example, a better ordering of menu items. New Tab Undo Close Tab --- Bookmark this Group of Tabs --- Reload Tab Reload all Tabs --- Close Tab Close other Tabs With the current implementation of "Close Tab(s)", it is extremely easy to inappropriately click (or just click) "Close Tabs" by accident. I have been silently griping about the implementation of this menu item for the past six to twelve months. I base my suggested menu ordering listed above upon the following routine scenarios: 1) I tend to almost always right click on the tab menu bar to create a "New Tab". 2) When clicking "New Tab", the mouse likely scrolls over "Close Tab" or "Close other Tabs" menu items (even briefly highlighting those destructive elements. 3) Overall, close tab menu items should just be "rock" bottom listed items to prevent clicking on this items by accident. If people want a more easier method of closing tabs, they (and I) can simply use keyboard CTRL keys. One thought for the "Close Tab" menu items, I always disliked moving the mouse to the far right of the display just to click the "X" icon for closing tabs.
I should mention, I meant to post the previous comment for the Seamonkey browser and not the Firefox browser. :-/
(In reply to Roger from comment #56) > I should mention, I meant to post the previous comment for the Seamonkey > browser and not the Firefox browser. :-/ That's OK, this is the SeaMonkey bug. (In reply to Roger from comment #55) [...] > I base my suggested menu ordering listed above upon the following routine > scenarios: > 1) I tend to almost always right click on the tab menu bar to create a "New > Tab". > 2) When clicking "New Tab", the mouse likely scrolls over "Close Tab" or > "Close other Tabs" menu items (even briefly highlighting those destructive > elements. With Ctrl+T, no mistake possible. Also not with "File ▶ New ▶ Browser Tab". > 3) Overall, close tab menu items should just be "rock" bottom listed items > to prevent clicking on this items by accident. If people want a more easier > method of closing tabs, they (and I) can simply use keyboard CTRL keys. I want it at top because that's what I use most often in that single-tab context menu. Very useful to close a *non*-current tab. > > One thought for the "Close Tab" menu items, I always disliked moving the > mouse to the far right of the display just to click the "X" icon for closing > tabs. I love it. At least it is at a fixed (and thus predictible) location. Moving the mouse across the whole screen is not really a big finger motion anyway, moving between the alphabetic keyboard and the numeric keypad, or between the keyboard and mouse, are farther. But I also use Ctrl+W for the current tab. "Close Tab" on the context menu I use mostly to close some non-current tab. So: different people, different choices. The current situation suits me fairly well, please don't take it away from me. But wait — Have you tried the "Menu Wizard" extension? https://addons.mozilla.org/addon/s3menu-wizard/ Maybe it does just what you want.
The menu options should probably be listed by priority of usage, and having a safe reasonable position within the menu. Most times the "Quit" option for any application is also listed at the bottom of the File menu list. The current listing order of the right click Tabs menu, is similar to putting the "Quit" option at the top of the list for the "File menu"! I personally don't think we should have to add add-ons to make an unreasonable option reasonable. The option should be generically safe from the vanilla compiled application. I took a look at the "Menu Wizard" by a Ukrainian. Are you sure the "Menu Wizard" will not hinder my browser experience while surfing pr0n? Of course, no pun intended.
Disclaimer: I am not the topic police in a forum, and my opinions are my own. Roger, working backwards, your comments are way out of line. There is no reason to insult an extension developer in such a way. The fact that the author is Ukrainian should have no bearing on anything. Oleksandr is a capable coder. That being said... What has any of this got to do with this bug, which deals with adding a close button to every tab in SM? Finally, this is not a discussion forum, but a bug tracker. It would be appreciated if further comments dealt with the subject of the bug in the ticket, and not with ancillary matters.
Would be nice if somebody else would then please advise if I should open a separate bug, or if this bug is adequate for my detailed report. (ie. My Comment #56.) With that said, I stand by with what I've previously stated. Mr. Rosenthal: I was trying to be nice (and not be more forth right and insensitive) and merrily touch upon my concern of security without further elaborating on my private Internet usage habits. (How anybody can take the time to target this one sentence from the majority of my comments, I don't know.)
Yes, comment #55 and following are off-topic for this bug. If you want to change the order of items in the context menu, please open a new bug report (and verify first that it's not pending yet). Thanks.
(In reply to Roger from comment #60) > Would be nice if somebody else would then please advise if I should open a > separate bug, or if this bug is adequate for my detailed report. (ie. My > Comment #56.) I have opened Bug 1214228 on this issue for you.
(In reply to Prognathous from comment #8) > Another vote AGAINST this RFE. Having the close tab button on each tab is > one of the worst usability issues with Firefox. The user actually needs to > "chase" the button every time a tab is closed. With SM, just keep the cursor > on the same spot and click click click to close tabs. Way better. > > Prog. Unless, of course, the cursor is in the window somewhere and the user then has to chase over to the rhs. If you don't like this proposed feature, you don't have to use it.
(In reply to trud from comment #63) > If you don't like this proposed feature, you > don't have to use it. Does that mean this would be implemented as an option? If so, will there be a user interface to enable and disable that option? Or will it be controlled via a hidden preference?
(In reply to David E. Ross from comment #64) > (In reply to trud from comment #63) > > > If you don't like this proposed feature, you > > don't have to use it. > > Does that mean this would be implemented as an option? If so, will there be > a user interface to enable and disable that option? Or will it be > controlled via a hidden preference? It is _already_ implemented as an option, sunce June 2006 in fact. AFAICT, there is no UI for it in the Preferences dialog; but it is not a "hidden" preference: even if you haven't set it, it is visible in about:config. If the "Config Descriptions" extension is installed (and enabled), an additional column is added to about:config, displaying the source comments for all preferences which have any, and this one (browser.tabs.closeButtons) does, as follows: Where to show tab close buttons: 0 on active tab only 1 on all tabs until tabClipWidth is reached, then active tab only 2 no close buttons at all 3 at the end of the tabstrip The default is 3; then of course for a more detailed description of this pref and its function there is always http://kb.mozillazine.org/Browser.tabs.closeButtons
Oops: sorry, it seems that the preference exists but doesn't work. On Firefox, it was added in Fx 2.0rc1 and removed in Fx 31. I have no information about whether it ever worked in SeaMonkey; but if the function is to be implemented, it will of course be by means of this preference.
The SeaTab X 2 extension puts the close button on the tab depending on the preference that Tony mentioned.
I installed SeaTab X 2 and all is well in my universe with this.
I believe tabminwidth should stay at 100, 50 seems too small. The title is practically useless at that width! 100 seems reasonable to me. Plus, both tabbrowser and tabmail have scrollable tabs now.
(In reply to Tony Mechelynck [:tonymec] from comment #65) > If the "Config Descriptions" extension is installed (and enabled), an > additional column is added to about:config, displaying the source comments > for all preferences which have any, and this one (browser.tabs.closeButtons) > does, as follows: > > Where to show tab close buttons: > 0 on active tab only > 1 on all tabs until tabClipWidth is reached, then active tab only > 2 no close buttons at all > 3 at the end of the tabstrip This RFE bug is for SeaMonkey. The addons.mozilla.org Web site describes the Config Descriptions extension as "Not available for SeaMonkey 2.39", the current SeaMonkey version.
(In reply to David E. Ross from comment #70) [...] > This RFE bug is for SeaMonkey. The addons.mozilla.org Web site describes > the Config Descriptions extension as "Not available for SeaMonkey 2.39", the > current SeaMonkey version. The mere fact that the page https://addons.mozilla.org/en-US/seamonkey/addon/config-descriptions/ can be displayed proves that the extension supports at least "some" version of SeaMonkey so let's look into it a little further. At the very bottom of that page, if you open the "Versions" foldout widget, you'll see that it supports "SeaMonkey 2.7 and later". The "and later" phrase means that this add-on does not require strict maxVersion checking. IOW, SeaMonkey builds equipped with the "autocompatibility" feature (which exists in SeaMonkey since version 2.1), and which, in addition, ave no lower a version than the minVersion set by the add-on (in this case 2.7) will accept to install the add-on irrespective of its maxVersion. There is a bug of addons.mozilla.org which might cause it to pop up a warning, "You need Firefox 10 or higher" if you try to install it straight from AMO. You may or may not see this, I'm not sure of the details. There are two separate workarounds, each of which alone should be enough: (a) Install first the "AMO Browsing for SeaMonkey" add-on, which makes AMO much more SeaMonkey-friendly. This extension is not yet available at AMO, its successive versions are hosted at http://addonconverter.fotokraina.com/amo-browsing/ . You should of course install the highest version. (b) Download the add-on to your own HD, then install it from there. I personally use this "Config Descriptions" add-on in SeaMonkey 2.43a1 with no problem, so IMHO its maxVersion of 2.18.* is bogus, just a sign of laziness on the part of its author.
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: