Two options here: Option A: * new profiles get shrinkable tabs as per chrome but * old profiles get scrolling tabs * as suggested in the doc, we'll add a user pref to toggle the behaviour Option B: * reduce the minimum size of a tab so that scrolling of tabs happens at a much higher tab count ( double? ) My tests on a macbook pro show that we start overflow at about 12 tabs whereas chrome's shrinking approach scales up to about 24 tabs before the "bread knife" becomes more or less useless.

BUG 681317 is related, but let's keep this one focused on the short term solution, i.e. users coming from / used to Chrome's behavior.

A few comments (already talked about this with Jeff & Madhava)... Option A (A Chrome-like tabstrip) is filled with enormous risk for 57/58. Our existing tabstrip implementation has historically been quite fragile/sensitive to changes like this (interactions between sizes and animations and scrolling and overflowing and thresholds (for hiding close buttons) and prefs and crusty code and ...). So we should really not pursue that until 59+, when we'd have a considered design and full Nightly cycle to shake out problems. Option B still carries some similar risk, but is plausible to look into. It looks like there's a single CSS min-width controlling this, and there have been some addons / userStyle.css tweaks that adjusted it. Mike Conley's putting together a test build that exposes a UI preference to change the min-width, so we can see if (1) it functions correctly (2) what a new min-width should be and (3) if this works well enough that we think it will address the concerns of former Chrome users who really want to use a faster browser but are used to their old tab strip. :)

A few areas we should look at if we do reduce the min-width, from chatting with Mike and Matt: * Likely going to require a number of test fixes for things relying on the old width * WebRTC indicators should be ok (they pulse over the favicon), but the tab audio indicator is shown between the title and close button. * Consider testing w/ tabs that don't have favicons (where the space is used by the title instead) * Anything in Tab Containers affected by this? (Probably not?) * We might(?) still have some prefs for controling tab-close button behavior (i.e. if it's shown on background tabs) / the threshold they disappear at * Any WebExtension impact? Not sure if there are APIs for addons to add things into the tab.

The patch I've posted adds a new pref, browser.tabs.tabMinWidth, which controls (surprise!) the minimum width of each tab before triggering tabstrip overflow. The preference is observed "live", so changing it should take effect immediately. I've exposed the preference hackily in about:preferences - it's in General under Tabs. I've got artifact try builds cooking, and I'll post a link here in a few moments to builds when they're done.

macOS build: https://queue.taskcluster.net/v1/task/NUrrVhkGR7m99R146SAT9w/runs/0/artifacts/public/build/target.dmg Win 32 build: https://queue.taskcluster.net/v1/task/Sz7Wjp9-RAaIU5TAxz4ZMQ/runs/0/artifacts/public/build/target.zip Win 64 build: https://queue.taskcluster.net/v1/task/UArGT4d7Sn2uI1RgUC26NA/runs/0/artifacts/public/build/target.zip Linux 64 build: https://queue.taskcluster.net/v1/task/Qggc9ZuiQOiBO866uZZEDg/runs/0/artifacts/public/build/target.tar.bz2

Are the builds in comment 6 sufficient for our purposes, or do I need to tweak at all?

(Note to folks on macOS: You'll need to go to System Preferences > Security & Privacy and _temporarily_ "allow apps downloaded from" anywhere in order to run this build, since it's not signed).

(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews from comment #7) > Are the builds in comment 6 sufficient for our purposes, or do I need to > tweak at all? Perfect, thanks! Over to Product and UX to play with.

Chrome vs Firefox 58, browser.tabs.tabMinWidth set to 50, 24 tabs open Some differences here, on chrome the tab title text is visible for the first 2-3 characters whereas on Firefox it's really maaaybe only the first character. Reducing the Firefox tab count to 20 instead of 24 provides up to 3 characters visible. Firefox's extra space on the top left vs chrome probably causes this. Stephen, what do you think?

Update: we discussed this and will be landing a change in 58 that provides the about:config preference and sets the default to 50, likely by tomorrow.

Regarding the WebExtensions question in Comment 3, there should be no conflict between this change and any existing tab API.

(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews from comment #5) > The patch I've posted adds a new pref, browser.tabs.tabMinWidth, which > controls (surprise!) the minimum width of each tab before triggering > tabstrip overflow. The preference is observed "live", so changing it should > take effect immediately. Please make this a boolean pref. This bug seems to lack some context; do UX people believe this behavior is preferable, Chrome aside? I don't think we want to end up with worse behavior long-term for the sake of matching Chrome. Considering that users opening many tabs tend to be power users who are comfortable with looking for and adjusting preferences, should we make this opt-in rather than enabling it in all new profiles? Or should we set the pref as part of profile migration from Chrome?

>I don't think we want to end up with worse behavior long-term for the sake of matching Chrome. Totally agree here. >Considering that users opening many tabs tend to be power users who are comfortable with looking for and adjusting preferences, should we make this opt-in rather than enabling it in all new profiles? Or should we set the pref as part of profile migration from Chrome? Even if you decide to set this preference as part of Chrome profile migration, I strongly suggest that a preference is available in the preferences UI (and not just in about:config), since it's very weird to get "undocumented" behavior when migrating from Chrome, that is different if a user creates a new profile (eg: if installing Developer edition without profile migration) that is hard to change. If it is visible in the preferences UI, it becomes a fully fledged preference that users can change ad-hoc -- even if a user prefers the Firefox behavior after having moved from Chrome. about:config is very power user functionality, especially given the warning that appears before edits are allowed.

Comment on attachment 8913866 [details] Bug 1404465 - Add browser.tabs.tabMinWidth to control minimum tab width, and set to 50 by default. https://reviewboard.mozilla.org/r/185266/#review191112 Driveby alert (sorry!) ::: browser/base/content/tabbrowser.xml:5833 (Diff revision 2) > + let clampedVal = Math.max(val, this._tabMinWidthLimit); > + let root = document.documentElement; FWIW, you could implement this with `defineLazyPreferenceGetter()` by passing it a transform function ( https://dxr.mozilla.org/mozilla-central/source/js/xpconnect/loader/XPCOMUtils.jsm#381-385 ). That might limit the amount of observe() boilerplate code as well. I believe the jsglobal magic in XPCOMUtils should be sufficient to ensure we clean up the pref observer when the window goes away.

(In reply to Dão Gottwald [::dao] from comment #13) > Please make this a boolean pref. I believe canuckistani requested this pref be such that the width could be set numerically, as opposed to just having two states. I think the idea is to keep this pref at _least_ until we're comfortable settling on a new min tab width, and perhaps even after. > This bug seems to lack some context; do UX people believe this behavior is > preferable, Chrome aside? I don't think we want to end up with worse > behavior long-term for the sake of matching Chrome. I believe the idea is that the overflow state is something that Chrome users find unintuitive, and that we should try to avoid it where possible. Reducing the tab mid width does not allow us to avoid tab scrolling entirely, but makes it less probable. Product (and up) were interested in exploring that trade-off. > Considering that users opening many tabs tend to be power users who are > comfortable with looking for and adjusting preferences, should we make this > opt-in rather than enabling it in all new profiles? Or should we set the > pref as part of profile migration from Chrome? Let's get feedback from our Nightly population with the new proposed minimum tab width, and then use that information to decide.

Comment on attachment 8913866 [details] Bug 1404465 - Add browser.tabs.tabMinWidth to control minimum tab width, and set to 50 by default. https://reviewboard.mozilla.org/r/185266/#review191112 > FWIW, you could implement this with `defineLazyPreferenceGetter()` by passing it a transform function ( https://dxr.mozilla.org/mozilla-central/source/js/xpconnect/loader/XPCOMUtils.jsm#381-385 ). That might limit the amount of observe() boilerplate code as well. I believe the jsglobal magic in XPCOMUtils should be sufficient to ensure we clean up the pref observer when the window goes away. Thanks Gijs, I think that simplified things nicely.

(In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews from comment #17) > (In reply to Dão Gottwald [::dao] from comment #13) > > Please make this a boolean pref. > > I believe canuckistani requested this pref be such that the width could be > set numerically, as opposed to just having two states. I think the idea is > to keep this pref at _least_ until we're comfortable settling on a new min > tab width, and perhaps even after. That seems to conflate different purposes unless I'm missing more context. Is the goal to ship the pref in the UI? Letting users enter a pixel size there seems way over the top in terms of customization that average users need. > > This bug seems to lack some context; do UX people believe this behavior is > > preferable, Chrome aside? I don't think we want to end up with worse > > behavior long-term for the sake of matching Chrome. > > I believe the idea is that the overflow state is something that Chrome users > find unintuitive, and that we should try to avoid it where possible. > Reducing the tab mid width does not allow us to avoid tab scrolling > entirely, but makes it less probable. Product (and up) were interested in > exploring that trade-off. In other words, the answer to my question is "no" / "not yet"? > > Considering that users opening many tabs tend to be power users who are > > comfortable with looking for and adjusting preferences, should we make this > > opt-in rather than enabling it in all new profiles? Or should we set the > > pref as part of profile migration from Chrome? > > Let's get feedback from our Nightly population with the new proposed minimum > tab width, and then use that information to decide. This will probably be very noisy. How are we going to evaluate this?

(In reply to Dão Gottwald [::dao] from comment #20) > That seems to conflate different purposes unless I'm missing more context. > Is the goal to ship the pref in the UI? Letting users enter a pixel size > there seems way over the top in terms of customization that average users > need. No, I don't believe we plan on exposing the preference in about:preferences. Instead, the idea is to allow UX (and folks from Product, and perhaps others) to tinker with that setting locally to see if we can settle on a decent default width. We may reach a point where we go, "Hey, we've settled on two minimum widths", then yeah, I'm happy to make this a boolean toggle. But I don't think we're there just yet. > In other words, the answer to my question is "no" / "not yet"? Not sure - I'll try again: > do UX people believe this behavior is preferable, Chrome aside? I believe UX thinks that tab scrolling is a pretty confusing UI affordance, and that if we can avoid it, we should. You might ask shorlander for more concrete detail there. > This will probably be very noisy. How are we going to evaluate this? I believe at some point UX or Product is going to come back with us with a sense of what a sensible new minimum width is going to be, once they've had an opportunity to tinker with it. The current hypothesis is that 50px is the right minimum width. I think we're going to evaluate this based on their subjective experience with the new default.

Comment on attachment 8913866 [details] Bug 1404465 - Add browser.tabs.tabMinWidth to control minimum tab width, and set to 50 by default. https://reviewboard.mozilla.org/r/185266/#review191154 ::: browser/base/content/tabbrowser.xml:5922 (Diff revision 3) > + "browser.tabs.tabMinWidth", this._tabMinWidthLimit, > + (pref, prevValue, newValue) => this.tabMinWidth = newValue, > + newValue => Math.max(newValue, this._tabMinWidthLimit), > + ); > + > + this.tabMinWidth = this.tabMinWidthPref; Hm, this isn't so "lazy" considering that we call the getter immediately after creating it. Can we move this line to some point later during initalization?

Comment on attachment 8913866 [details] Bug 1404465 - Add browser.tabs.tabMinWidth to control minimum tab width, and set to 50 by default. https://reviewboard.mozilla.org/r/185266/#review191154 > Hm, this isn't so "lazy" considering that we call the getter immediately after creating it. > > Can we move this line to some point later during initalization? > Hm, this isn't so "lazy" considering that we call the getter immediately after creating it. That's true, but I'm not really using the lazy stuff so that we defer getting at the pref until the last moment, but rather so that I can take advantage of the observation / transformation stuff that Gijs mentioned in that earlier review. Are you okay with me landing as is?

Comment on attachment 8913866 [details] Bug 1404465 - Add browser.tabs.tabMinWidth to control minimum tab width, and set to 50 by default. https://reviewboard.mozilla.org/r/185266/#review191154 > > Hm, this isn't so "lazy" considering that we call the getter immediately after creating it. > > That's true, but I'm not really using the lazy stuff so that we defer getting at the pref until the last moment, but rather so that I can take advantage of the observation / transformation stuff that Gijs mentioned in that earlier review. > > Are you okay with me landing as is? Yeah you can land as is. We do a fair amount of pref reading during startup anyways as is.

Pushed by mconley@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/a75e0386aad8 Add browser.tabs.tabMinWidth to control minimum tab width, and set to 50 by default. r=jaws

(In reply to Dão Gottwald [::dao] from comment #13) ... > > This bug seems to lack some context; do UX people believe this behavior is > preferable, Chrome aside? I don't think we want to end up with worse > behavior long-term for the sake of matching Chrome. > > Considering that users opening many tabs tend to be power users who are > comfortable with looking for and adjusting preferences, should we make this > opt-in rather than enabling it in all new profiles? Or should we set the > pref as part of profile migration from Chrome? This patch is not intended to match the behaviour of chrome per se, the intent is instead to make the least invasive change that will solve the problem we're seeing. The problem is this: 1. for a given screen size, Firefox can only display a relatively low number of tabs on-screen before sending some tabs into overflow. In my ( incomplete ) tests, I've discovered that chrome can display something like double the number of tabs before their solution becomes difficult to use. 2. we have feedback from chrome users who typically browse with lots of tabs open that Firefox's tab strip implementation doesn't scale as well as chrome for what they want - having all or as many tabs visible to the user as possible 3. when we got this feedback we discussed the issue and concluded that the current behaviour of Firefox could scale to a goal of having double the number of tabs visible before scrolling by adjusting the min0-width setting here, but we wanted feedback on the change before committing to it in 58 or uplifting to 57. I should add: most users will never see this change because they do not open enough tabs. In my own experiments on my laptop, this increases the number of possible visible tabs before scrolling from 12 to 24 (ish). Stephen agrees this is a dramatic improvement over the current behaviour.

I did a quick mockup of an active tab with the audio icon visible between the favicon and the active closing button. Keeping left and right padding as well as the spacing between the icons the same, the tab has (requires!?) a width of 72px. (In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #10) > Created attachment 8914385 [details] > DisplaysExtra_and_NotificationCenter_and_Item-0.png > > Chrome vs Firefox 58, browser.tabs.tabMinWidth set to 50, 24 tabs open > > Some differences here, on chrome the tab title text is visible for the first > 2-3 characters whereas on Firefox it's really maaaybe only the first > character. Reducing the Firefox tab count to 20 instead of 24 provides up to > 3 characters visible. Firefox's extra space on the top left vs chrome > probably causes this. On a side note, the screenshot compares 25 tabs in Firefox to 23 tabs in Chrome ;)

50 is way too short! I can only see the favicon and the first letter of the title, so it's not possible to distinguish tabs from the same domain. So bad UX. I really think you should increase the default minimum width.

(In reply to Oriol Brufau [:Oriol] from comment #30) > 50 is way too short! I can only see the favicon and the first letter of the > title, so it's not possible to distinguish tabs from the same domain. So bad > UX. I really think you should increase the default minimum width. Well... I have currently 123 opened tabs (what a nice search/working crazy thing!), tabs has 36px... and it is great (almost faviconized tabs, yes)

(In reply to Oriol Brufau [:Oriol] from comment #30) > 50 is way too short! I can only see the favicon and the first letter of the > title, so it's not possible to distinguish tabs from the same domain. So bad > UX. I really think you should increase the default minimum width. Can you try 70? I'm using that right now and it seems pretty good.

To test this: * change the value of 'browser.tabs.tabMinWidth' in about:config to a specific number, say 70 * open enough tabs so that overflow triggers, then close two tabs, then open a tab ( we retain overflow until 2 tabs have been closed! ) * count the number of tabs opened * open chrome and open that number of tabs * compare the utility of each browser For my own purposes 70 is looking pretty good, YMMV

Once the minimum tab width is reached, tabs without favicons are narrower than tabs with favicons. Is this expected? For your testing convenience, https://www.example.com/ is a website without a favicon. btw, I also prefer tabMinWidth 70 over 50.

(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #32) > Can you try 70? I'm using that right now and it seems pretty good. Yes, I prefer 100, but 70 is good.

100 seems to be about enough to keep an entire 7-digit bug number visible; 70 is too small for that, and 50 barely even shows the first digit.

On today's nightly the minimum size of tab had shrink, and we got some user compliment for it on local channels. Where is the right place to issue such comments about this UX change that we can point those angry user to? (I know that bugzilla is not right place) One of the advantage Firefox over Chrome local user keep promoting is "You can at lease understand the tab on Firefox with overflow scrolling when it's too many".

I'd like some place to know about these changes (and countermeasure against them) too (and perhaps feedback?). Searching bugzilla is hard to find these, and Google lags behind.

(In reply to Mark Mayo [:mmayo] from comment #1) > let's keep this one focused on the short term solution, i.e. users coming > from / used to Chrome's behavior. (In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews from comment #17) > I believe the idea is that the overflow state is something that Chrome users > find unintuitive, and that we should try to avoid it where possible. I’m confused about this: Why are *Chrome* users more relevant that established Firefox (power) users? I know a lot of people (power users) who believe Chrome is already unusable for the simple fact that at a high tab count, the tab strip is no longer of any use. All it gives you is the information that there are a lot of tabs, without a chance to actually manage them. It’s btw. interesting how Chrome’s behavior appears to be the favored one when Chrome at some point actually stop rending new tabs completely: Not only do all the tabs only consist of a single “peak” (with neither icon nor text), but they are limited to a maximum amount before they start being rendered *behind* the “new tab” button and disappear into nowhere. (In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #26) > (In reply to Dão Gottwald [::dao] from comment #13) > The problem is this: > > 1. for a given screen size, Firefox can only display a relatively low number > of tabs on-screen before sending some tabs into overflow. In my ( incomplete > ) tests, I've discovered that chrome can display something like double the > number of tabs before their solution becomes difficult to use. But at that point, Chrome’s tab list also contains *zero* information. Even if I have few enough tabs that the favicon is still displayed (which Chrome stops doing at some point btw!), the favicon alone is no help at all in identifying an individual tab. It’s not unlikely that I have around 30 tabs on GitHub open—next to each other. There is really no use in seeing 30 GitHub favicons next to another: I will have to click every single one of them to find the one I need. On the other hand, the classic Firefox behavior allows me to easily see what the tab actually contains. Sure, I have to scroll, but scrolling is not a bad thing [1] — even when done vertically. It’s easy enough for power users to realize that the scroll wheel works for it, or that they can use the arrow buttons on the side, OR that they can click the drop down to access more tabs. This discussion really shouldn’t be about numbers but about the information tab buttons contain and whether that is appropriately covered with this change or not. I don’t believe it is at a size of 50 when the tab has a favicon. The popular number 70 is okay-ish but it also only displays 5 characters from the title, which isn’t really much either. [1] http://uxmyths.com/post/654047943/myth-people-dont-scroll > 2. we have feedback from chrome users who typically browse with lots of tabs > open that Firefox's tab strip implementation doesn't scale as well as chrome > for what they want - having all or as many tabs visible to the user as > possible So take the feedback from Firefox users who typically browse with lots of tabs open that Chrome’s tab strip implementation doesn’t scale as well as Firefox for what they want – having as much as information on tabs visible to the user as possible. (Sorry, but seriously, why do Chrome users matter here so much?) > 3. when we got this feedback we discussed the issue and concluded that the > current behaviour of Firefox could scale to a goal of having double the > number of tabs visible before scrolling […] But why is the sheer *number* of displayable tabs even of interest? Shouldn’t the *value* behind the tabs be a lot more important, especially from an UX view point? > I should add: most users will never see this change because they do not open > enough tabs. But those users who do see this change will likely be hurt the most by it. (In reply to Mike Conley (:mconley) (:⚙️) - Backlogged on reviews from comment #17) > Let's get feedback from our Nightly population with the new proposed minimum > tab width, and then use that information to decide. Well, I’m certainly not happy about this. I’m lucky enough that I’m capable of digging up these bugzilla issues, so I could learn about the preference and also voice my opinion about this change. But I fear that a lot of users that will be hit by this, will not have this chance so they will just have another changed thing with Firefox that they don’t like. I strongly suggest integrating this into the customization UI. Just like we recently got a “Density” drop down to change the density of the UI controls, I could easily see a “Minimum tab width” drop down with the most common values (50, 70, 100, 150?) in there.

(In reply to Patrick Westerhoff from comment #39) > [...] > allows me to easily see what the tab actually contains. Sure, I have to > scroll, but scrolling is not a bad thing [1] — even when done vertically. > It’s easy enough for power users to realize that the scroll wheel works for > it, or that they can use the arrow buttons on the side, OR that they can > click the drop down to access more tabs. Scrolling seldom bothers me: for the most time all the relevant tabs I'm going to use next are in sight. I hate the default value, but I like the pref, because I can change it to a larger value when the title text doesn't differentiate them enough; some badly designed sites have the most significant information in title at the right. Sadly the great Tab Groups extension is gone, together with some multiline tab extensions. I hope this useful feature doesn't disappear in the future (lots of features I use start to hide behind a pref, then get completely removed in the past).

(In reply to Oriol Brufau [:Oriol] from comment #35) > (In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #32) > > Can you try 70? I'm using that right now and it seems pretty good. > > Yes, I prefer 100, but 70 is good. I'm also voting for 100, 70 is not enough to distinguish similar pages, and 50 is unusable, only the favicons are visible with a fading first character

Better late than never, I tried to explain why tabscroll is bad and how power users used to prevent it by shrinking the minimum width 7 years ago, when a patch removing the about:config preference was landed ( https://bugzilla.mozilla.org/show_bug.cgi?id=574654#c23 ), and I welcome the reintroduction of this preference, thank you very much!

UI that makes tab title invisible is too bad. Mozilla is licking the UI. :( Mozilla needs to think UI seriously. I think it is better to make the taba vertical, is not it? Why is not it implemented.

This completely destroys my workflow. I hate Chrome's tab management, and I was hoping Firefox would improve its own instead of making it worse.

I use browser.tabs.tabMinWidth 75 and multirow tab bar.

I guess I'll settle with 110 for now, seems good. Instead of this, Panorama or some other actual tab management should be implemented, instead of making the tabbar unusable.

After a bunch of conversations I'd like to re-spin and land the patch with 70 as the default, then request uplift. Mike, can you get that running? r=shorlander

Stephen, what do you think? ^^

> I’m confused about this: Why are *Chrome* users more relevant that established Firefox (power) users? I know a lot of people (power users) who believe Chrome is already unusable for the simple fact that at a high tab count, the tab strip is no longer of any use. All it gives you is the information that there are a lot of tabs, without a chance to actually manage them. As a data point, I'm an "established Firefox user" (been a user of a Mozilla browser since I switched from Internet Explorer to pre-1.0 Mozilla Suite with only a very brief detour to Chrome when it initially came to Linux), and I put a lot of effort into ENABLING the Chrome-style behaviour. (In fact, discovering the userChrome.css-based solution checked off one of my requirements for moving off 52 ESR into WebExtensions-era Firefox, though I'm still on ESR while I evaluate native download managers as options for replacing DownThemAll should bug 1245652 and bug 1254327 not get fixed quickly enough.) I consider "shrink to favicons and no smaller, allow tooltips to distinguish between things from the same site and AwesomeBar to jump to a known tab by title" to be the best of both worlds. > But at that point, Chrome’s tab list also contains *zero* information. Even if I have few enough tabs that the favicon is still displayed (which Chrome stops doing at some point btw!), the favicon alone is no help at all in identifying an individual tab. It’s not unlikely that I have around 30 tabs on GitHub open—next to each other. Not everyone uses it that way. When I have enough tabs to crunch it down into favicons, one of two case almost always applies: 1. I just middle-clicked a ton of links and the order in which I handle them is unimportant. 2. I don't have more than half a dozen of the same icon in a given cluster, clusters are more likely to be something I can visually identify purely by the distinctive sequence of favicons, and it's easy to click one and flip through the rest using the scroll wheel, because I use an extension to bring Firefox into line with the "scroll wheel switches active tab" convention the rest of the Linux desktop (including Chrome) follows. In my case, when I have enough tabs for them to have shrunk down, I'm operating at a scale where getting an overview of the tab groups is more important than being able to read every tab at a glance. > Sure, I have to scroll, but scrolling is not a bad thing [1] — even when done vertically. It’s easy enough for power users to realize that the scroll wheel works for it, or that they can use the arrow buttons on the side, OR that they can click the drop down to access more tabs. Except that, as a Linux user, Firefox's use for scrolling directly contradicts the intuition and muscle memory built by the Linux platform convention which Chrome already follows: Scroll switches active tab. Enabling scroll wheel to switch tab focus in Firefox to match the rest of the desktop has always been one of the tweaks I set up first and it's one of the un-resolved entries on my 52ESR->WebExtensions migration checklist. (If ESR runs out before the necessary APIs are finished, I'll take advantage of X11's dangerously permissive model to overlay an "unmanaged" 0% opacity window at the top of Firefox which proxies through every event except the scroll wheel, and translates that to Ctrl+Tab/Ctrl+Shift+Tab.)

>Except that, as a Linux user, Firefox's use for scrolling directly contradicts the intuition and muscle memory built by the Linux platform convention which Chrome already follows: Scroll switches active tab. I'm also a Linux user, and I just took a look at caja and epiphany-web, both of which do tab scrolling. Epiphany doesn't allow tabs to get tiny, but caja does. I also took a look at mate-terminal, which allows tabs to get tiny, and also allows tab switching via mouse-wheel scroll. So this behavior is inconsistent at best. As another long time Firefox user (and Mozilla Suite, and Camino at times), 50 is far too small; I'm another user who opens up hundreds of tabs, and tens of them within single windows (using awesomebar tab search most of the time to switch tabs, but also visually by using ctrl+tabs or ctrl+shift tabs to while observing the screen). Clearly, clicking on tabs in Chrome when favicons are no longer shown would be fairly useless in that use-case except when looking at tab contents -- that's basically "mystery meat" navigation where I just have to click buttons until I stumble into what I want. Using 70 now and I could likely live with it, but I would echo prior statements that we should build something into the customize UI (alongside say, the density settings) to customize this -- I don't think there's any need for a numerical field (leave it in about:config), but a dropdown with options like "short", "medium" or "long", with values of 50, 75, 100 would be really ideal. If we're importing Chrome settings, we could default the user to 50 in order to maintain their (presumed) existing expectation, but for existing Firefox users, we could migrate to 75 (in order to push a preference that product/engineering think is "better/more desirable", leaving the 100 option (and the about:config preference) readily available in the customize UI (like we do for density). I would dislike if this was simply defaulted and not available as a visible user preference -- clearly, there is some precedent for this, with the unified search bar being tested. Beyond that, if things are not available as user preferences, desired behaviors are easier to ignore (is there a chance that this preference could be collected via a new telemetry probe?) since they don't appear on the radar of Mozilla team members.

> I consider "shrink to favicons and no smaller, allow tooltips to distinguish between things from the same site and AwesomeBar to jump to a known tab by title" to be the best of both worlds. Tooltips are slow to show up, and you can only read one at a time. The best of both worlds is customizeable. I'm glad there is a pref to tweak but I'm afraid of it going away because it's not easy to discover, so there will be less and less users using it. > Except that, as a Linux user, Firefox's use for scrolling directly contradicts the intuition and muscle memory built by the Linux platform convention which Chrome already follows: Scroll switches active tab. I'm also a Linux user, but I have never tried to scroll on horizontal tabs because the wheel scrolls vertically. When I need to jump between many tabs, I'll use the little dropdown menu which clearly shows all the titles along with favicons. In the old time the disappearing tabs might take new users some time to discover, but with current visual shadow hint I know there are hiddle tabs at first glance. > but a dropdown with options like "short", "medium" or "long", with values of 50, 75, 100 would be really ideal I like this idea! But I don't think 100px is long. Maybe 140px? I don't know the previous value between this change is. > I would dislike if this was simply defaulted and not available as a visible user preference Me too. It won't bother me unless the pref disappears, since I already know it (there are several prefs I'll change from default, one more isn't a big deal). But it will affect other users who don't know. Many users won't be able to find prefs so they will live with the default, so less and less users will use it, until one day Mozilla thinks nobody is using it so they remove the pref.

> I'm also a Linux user, and I just took a look at caja and epiphany-web, both of which do tab scrolling. Epiphany doesn't allow tabs to get tiny, but caja does. I also took a look at mate-terminal, which allows tabs to get tiny, and also allows tab switching via mouse-wheel scroll. So this behavior is inconsistent at best. I'm not sure I understand. Do you mean that the "allow tabs to get tiny" is inconsistent? That wasn't what I was referring to when I talked about platform convention. I was talking about how, because "scrolling switches active tab" is baked into GTK+ and Qt tab pane widgets and aped by applications which don't use them, such as Chrome, my muscle memory is built around quickly zipping to and fro using the scroll wheel, which developed into a habit of dealing with the "long-lived clusters of identical icons are never more than half a dozen" situations I produce by clicking on one end, then scrolling through to what I want. The "allow tabs to get tiny" is simply something I choose a browser/extension/config based on in order to allow the kind of visual overview I want. > Clearly, clicking on tabs in Chrome when favicons are no longer shown would be fairly useless in that use-case except when looking at tab contents I fully agree. Thankfully, the only situation where I encounter that Chrome mis-behaviour is when I'm using a Chrome Incognito Window in a purely serial fashion where I middle-click massive numbers of image links so the later ones can load in the background while I look at, possibly Ctrl+S, and then Ctrl+W the earlier ones. (Chrome because single-process Firefox bogs down unusably in that use case.) In fact, Chrome is actually worse than that. If you have enough tabs open, they DO eventually stop shrinking... but now you have an unknown number of tabs invisible off the right end of the strip... possibly including the currently selected one. > Using 70 now and I could likely live with it, but I would echo prior statements that we should build something into the customize UI (alongside say, the density settings) to customize this -- I don't think there's any need for a numerical field (leave it in about:config), but a dropdown with options like "short", "medium" or "long", with values of 50, 75, 100 would be really ideal. Again, agreed. That'd be similar to what the legacy extensions I've used over the years converged on and it works nicely.

> I'm also a Linux user, but I have never tried to scroll on horizontal tabs because the wheel scrolls vertically. Maybe it's because I'm a programmer, but I have a "try every major input on a new widget type to see what I can find" mindset and, even if I didn't, it seems natural to me that the scroll wheel is mapped to "primary scroll axis" rather than a specific direction. > When I need to jump between many tabs, I'll use the little dropdown menu which clearly shows all the titles along with favicons. If my use doesn't predate the dropdown menu, it certainly predates my knowing about it by at least half a decade. Either way, I find the reading and precision mousing involved in using the menu much slower than just slamming the mouse to the top of the screen (unbordered, maximized window) and spinning the wheel a known number of clicks (near) or a known approximate distance and then a few clicks (far).

>I'm not sure I understand. Do you mean that the "allow tabs to get tiny" is inconsistent? That wasn't what I was referring to when I talked about platform convention. > >I was talking about how, because "scrolling switches active tab" is baked into GTK+ and Qt tab pane widgets and aped by applications which don't use them, such as Chrome, my muscle memory is built around quickly zipping to and fro using the scroll wheel, which developed into a habit of dealing with the "long-lived clusters of identical icons are never more than half a dozen" situations I produce by clicking on one end, then scrolling through to what I want. No, in my testing, only mate-terminal actually switched tabs when scrolling in the tab area. Caja and Epiphany did not.

> No, in my testing, only mate-terminal actually switched tabs when scrolling in the tab area. Caja and Epiphany did not. That's odd. Given that I know Epiphany is a GTK+ application, either that's an application-specific behaviour or there's some way to change the default, because, last time I checked, it was present by default when I whipped up some minimal test applications using PyGTK and PyQt. ...and I just double-checked that tab-wheel scrolling switches the active tab in the following "tabbed browsers" that I happen to have installed at the moment: Web: - Chromium - Midori (GTK+) - Arora (Qt) - Konqueror (Qt) Filesystem: - PCManFM (GTK+) - Thunar (GTK+) - Dolphin (Qt) - Konqueror (Qt) (The spread of installed file managers is a leftover from when I was narrowing down exactly what was causing Firefox to refuse drag-and-drop uploads that Chrome is perfectly fine with. The still-mistitled bug 1383372 resulted from that.)

>Web: > - Chromium > - Midori (GTK+) > - Arora (Qt) > - Konqueror (Qt) FWIW, I just installed and tried Qupzilla and Midori. Qupzilla switches tabs when scrolling over them. Midori does not for me. Either way, this is all pretty off topic, so I think we should stop talking about this. It looks like this feature was removed from GTK at one point: https://bugzilla.gnome.org/show_bug.cgi?id=630226 and has been requested again: https://bugzilla.gnome.org/show_bug.cgi?id=145244 - but the enhancement request is still set as NEW (not resolved).

I just saw this land in my Nightly install, so... bikeshedding time! :) 50px is too small and 70px would be the absolute bare minimum for me. For a default setting, I think somewhere around 80-85px is a reasonable compromise and would still fit in more tabs than the current 100px.

I am also uncomfortable with the 50px. Dropping here a few small UX suggestions, in the unlikely case UX hasn't thought about some of them yet. 1. The separation between pinned tabs and shrunken tabs should be made explicit. The first time I saw the 50px tabs, I thought that there was a bug in Session Restore and that everything had been converted to pinned tabs. Later, I just had trouble recognizing which were my pinned tabs and which weren't. 2. Replace the tab tooltip by something that (nearly immediately) displays the favicon and full title, using the same font and color as the tab. This would need to show more immediately than the current tooltip, to help finding one tab among many of the same favicon. 3. Provide some UX to customize the size of tabs. I'm thinking of displaying a col-resize cursor that would let us customize the width of all non-pinned tabs when we are in the customize dialog. 4. For power users, add a "filter tabs" feature, which is basically what was available in tab center.

(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #47) > After a bunch of conversations I'd like to re-spin and land the patch with > 70 as the default, then request uplift. > > Mike, can you get that running? > > r=shorlander According to comment 27, 70 is still not feasible, and I'm not even sure if comment 27 took touch mode into account where the close button is bigger.

Another problem with a too small value is that with Photon Firefox has a dark tab strip by default and a lot of web sites have favicons which are optimized for light tab strips. So on some web sites the favicon is nearly invisible which makes the tab title more important compared with Firefox < 57. --- I tested different values and I feel the current default of 100 as very pleasant. I see 80 as the absolute minimum, below 80 Firefox is difficult to use for me. I have a lot of open tabs and for my browsing experience a small tab width is no advantage with a lot of tabs but a disadvantage. I have a lot of tabs of the same domain and with the same favicon open, so I need a part of the tab title.

(In reply to David Teller [:Yoric] (please use "needinfo") from comment #58) > I am also uncomfortable with the 50px. Dropping here a few small UX > suggestions, in the unlikely case UX hasn't thought about some of them yet. > > 1. The separation between pinned tabs and shrunken tabs should be made > explicit. The first time I saw the 50px tabs, I thought that there was a bug > in Session Restore and that everything had been converted to pinned tabs. > Later, I just had trouble recognizing which were my pinned tabs and which > weren't. Can you try a setting of 70? This should address that issue.

I'm going to close this bug out and file a new one to do the switch to 70px - this one has gotten really noisy.

(In reply to Jeff Griffiths (:canuckistani) (:⚡︎) from comment #61) > (In reply to David Teller [:Yoric] (please use "needinfo") from comment #58) > > I am also uncomfortable with the 50px. Dropping here a few small UX > > suggestions, in the unlikely case UX hasn't thought about some of them yet. > > > > 1. The separation between pinned tabs and shrunken tabs should be made > > explicit. The first time I saw the 50px tabs, I thought that there was a bug > > in Session Restore and that everything had been converted to pinned tabs. > > Later, I just had trouble recognizing which were my pinned tabs and which > > weren't. > > Can you try a setting of 70? This should address that issue. Indeed, it works much better at 70. Still, that's not a solution for most users.

I meant "changing manually is not a solution for most users", but I now realize your intent and the fact that you are probably aware of that. Please ignore the last sentence of my previous comment :)

I have reproduced this bug with Nightly 58.0a1 (2017-09-29) on Windows 10, 64 Bit! This bug's fix is verified with Release & latest Beta! Build ID : 20171112125346 User Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:57.0) Gecko/20100101 Firefox/57.0 Build ID : 20171218174357 User Agent : Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:58.0) Gecko/20100101 Firefox/58.0