Closed
Bug 268213
Opened 20 years ago
Closed 6 months ago
Decrease minimum tab width (allow more tabs before invoking overflow menu)
Categories
(Camino Graveyard :: Tabbed Browsing, enhancement)
Tracking
(Not tracked)
RESOLVED
INCOMPLETE
People
(Reporter: alqahira, Unassigned)
References
Details
Attachments
(2 files)
4.17 KB,
patch
|
Details | Diff | Splinter Review | |
31.67 KB,
image/png
|
Details |
User-Agent: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041106 Camino/0.8+ Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8a5) Gecko/20041106 Camino/0.8+ With the new tabs in the 0.8+ nightlies, the smallest width tab can have before the overflow menu begins is ca. 100 px (it varies with screen size, resolution, and Camino window size--this number is from a 17" PB, 1440x900, Camino at full width--the minimum width increases as the window size decreases). There's been some grumbling in the MozillaZine forum both about the overflow menu itself and about the fact the new tabs don't shrink as much as the old ones did (or that one can't get as many tabs displayed on the tab bar as in the past). The overflow menu is also a little "awkward" because one only sees "part" of the interface for the current tab if it's in the overflow menu--the location bar part, but not the active tab (on the tab bar) itself (still a huge improvement over the old 16 tab limit+extra tabs in new windows, though!). In order to address all of these issues, it would be nice if the minimum tab width could be decreased. My personal preference would be to decrease the minumum tab width to just the amount of space needed for the close box and the favicon and appropriate padding. This (or really any decrease in the minimum width) is probably dependent on bug 183279 (tooltips for tab titles) and bug 162893 (favicons referenced by LINK element are not displayed) being fixed, as those two bugs provide info that would make "tiny tabs" distinguishable from each other easily (sight or mouseover). This takes the strenghts of both styles of tabs and makes the result better (I think). Reproducible: Always Steps to Reproduce: 1. Open a bunch of tabs Actual Results: Tabs never get smaller than ca 100 px, and a certain small number of tabs--8, or half of the old style tabs, at my usual window width, but this varies depending on screen width, resolution, and window width--before the overflow menu is invoked Expected Results: Shrink tabs' widths to approx. close box+favicon+padding before invoking the overflow menu
Comment 1•20 years ago
|
||
I agree; I think the minimum of 100px tabs is somewhat low, as I frequently have more than 9 (in my case) tabs open. I don't know if limiting it to just the favicon and the close button is reasonable, but I don't think 100 px is very reasonable either. If we decide on keeping the current tab width, I would recommend that the tab bar always keep the current page highlighted, shifting if necessary. Example: If Camino overflows at 8 tabs, and I'm at tab 10, the tab bar should display tabs 9 through 16. There should be overflow arrows on both the left and right sides that work just like the current overflow arrow. (I can file a separate bug on this if requested.)
The problem with this bug is that everybody has different needs. The main reason it is 100 px at the moment is to make sure website titles are well visible and are not cut. But maybe we could decide to use 75px instead as the minimum tab width. I guess we need to test this a little. It's an easy enough fix even I can provide.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Target Milestone: --- → Camino1.0
Reporter | ||
Comment 3•20 years ago
|
||
(In reply to comment #2) > The main reason > it is 100 px at the moment is to make sure website titles are well visible and > are not cut. But maybe we could decide to use 75px instead I understand; I think 100px is really the smallest possible to keep a useful title--y'all make good decisions! :) 75px looks to me like 4 characters + ellipsis (vs 8 + ellipsis at 100px), not enough :( That's why I suggested that shrinking should be dependant on fixing bug 183279 and bug 162893 (although I don't think I have the power to add that dependency formally, and certainly couldn't input them on the "reporting a bug" form). Then there would be alternate methods of displaying the title and recognizing the site.
Reporter | ||
Comment 5•20 years ago
|
||
Since I now have the power to do so, adding the dependency on bug 183279 and bug 162893. This is not a "hard" or technical dependency but rather one that ensures a good UI/ease-of-use (make the tiny tabs distinguishable visually when the displayed titles are 3 characters long...).
Comment 6•20 years ago
|
||
In Mozilla/Firefox minimum tab width can be set with a userChrome.css statement (see bug 196322).
Updated•19 years ago
|
Target Milestone: Camino1.0 → Camino1.1
Comment 7•19 years ago
|
||
Here's another vote in favour of a (hidden) preference to allow users to set a minimum width. Once we get bug 183279 fixed, the necessity of having wider tabs really goes out the window, IMO, as the tooltip will provide a full title and URL. cl
Updated•19 years ago
|
Assignee: mikepinkerton → d.elliott
Updated•19 years ago
|
QA Contact: tabbed.browsing
Updated•19 years ago
|
Status: NEW → ASSIGNED
Comment 8•18 years ago
|
||
What is the status of this bug? Nobody appears to have reviewed the patch that already exists and I am constantly prodding around BrowserTabBarView.mm so we may as well get this sorted.
Comment 9•18 years ago
|
||
The status is that this patch just reduces the minimum width. We decided in the big meeting and the wiki conversations that followed it that what we should be doing is leaving the minimum width at its current value, but providing the user some way to change that (either via about:config, or or with a resize-drag on the edge of any tab)
Comment 10•18 years ago
|
||
Oh, I'm sorry. Looks like this patch does add a hidden pref. So the status is that we should decide whether that's what we want, or if we want the minimum tab width settable via the drag-on-edge-of-a-tab method. I support the second. I think it's an intuitive, unobtrusive, and shiny way of changing the width of all tabs.
Comment 11•18 years ago
|
||
I am not currently working on this, freeing it up.
Assignee: d.elliott → nobody
Status: ASSIGNED → NEW
Updated•18 years ago
|
Target Milestone: Camino1.1 → Camino1.2
Reporter | ||
Comment 12•18 years ago
|
||
Mass un-setting milestone per 1.6 roadmap. Filter on RemoveRedonkulousBuglist to remove bugspam. Developers: if you have a patch in hand for one of these bugs, you may pull the bug back to 1.6 *at that point*.
Target Milestone: Camino1.6 → ---
Comment 13•15 years ago
|
||
(In reply to comment #10) > Oh, I'm sorry. Looks like this patch does add a hidden pref. So the status is > that we should decide whether that's what we want, or if we want the minimum > tab width settable via the drag-on-edge-of-a-tab method. I support the second. > I think it's an intuitive, unobtrusive, and shiny way of changing the width of > all tabs. Presumably the latter would have to create a pref of some sort anyway, so it really addresses both. I think if we're going to do this, making the edge of tabs draggable is the most Mac-like way to do it. This sort of got lost in the last couple years, but we probably ought to make a decision one way or another. I'm still in favour of *something*, but it's not a particularly common request amongst our users (maybe four or five requests on the forum in the past two years), so that might be a pretty good argument for WONTFIX.
Hardware: PowerPC → All
Reporter | ||
Comment 14•15 years ago
|
||
My feelings on this have changed substantially since comment 0; overflow has improved considerably, and we have scrolling and rearranging now, too. At my standard window width (883px), our tabs are all of 1px wider than Safari's (103px vs 102px) and we show the same number of tabs (8). At a very small window width (the smallest window that allows 2 tabs + scroll/overflow widgets), our tab width is 99px. We basically allow for 8 characters of title text (or 7 characters and an elipsis). I can't imagine tabs being usable much smaller than this. Second, if we allowed user-resizing, we'd need to condition it on some modifier (option?), because between tab dragging and site icon dragging and close-button clicking, normal click-and-drag behaviors are pretty crowded on the tab. Finally, I'm not sure there's enough demand to support the amount of work this would take to implement (reworking the tab drawing/sizing code + implementing the resizing mechanism/animation). Frankly, I'd much rather the time/effort that would be required be put towards animation for scrolling tabs and the ability to scroll the tab bar while dragging to rearrange. My vote is WONTFIX.
Reporter | ||
Comment 16•14 years ago
|
||
I think we should just WF this, per thoughts a year and a half ago. Bug 628418 is probably a better way to address whatever part of this that still remains for those 5 people, I think.
Status: NEW → RESOLVED
Closed: 6 months ago
Resolution: --- → INCOMPLETE
You need to log in
before you can comment on or make changes to this bug.
Description
•