User-Agent: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a1pre) Gecko/2008071603 Minefield/3.1a1pre Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1a1pre) Gecko/2008071603 Minefield/3.1a1pre If the browser.ctrlTab.previewsCount is set to anything higher than 3, only the 2nd tab will act focused instead of the middle one. Reproducible: Always Steps to Reproduce: 1. Set browser.ctrlTab.previewsCount to higher than 3 (eg. 5) 2. 3. Actual Results: 2nd preview is big. Expected Results: 3rd or middle preview is big.

I'd like to drop browser.ctrlTab.previewsCount altogether. The patch in bug 445369 does that.

So does that mean only 3 previews will be displayed at once? Or will it be based on the users browser size?

(In reply to comment #2) > So does that mean only 3 previews will be displayed at once? Yes.

That's disappointing to hear. Within 5 minutes of discovering the ctrl-tab panel, I bumped previewsCount up to 6, as I quickly found 3 to be a bit to restrictive for quick, effective use. I certainly don't mean to belittle the effort that was put in to it, but if it can't be easily (dynamically) controlled (i.e. changing the number of previews and their ordering with out needing to restart), then I think that speaks of deficiency in either the design or implementation. There's no reason not to provide this functionality, and I think doing so would be in keeping with Firefox's traditions of user control.

I also have to agree to the last comment. If you really want to switch through the list of tabs in a fast manner it's hard not to miss the right tab. Further I can see the same behavior with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1a1pre) Gecko/2008071806 Minefield/3.1a1pre ID:2008071806

The purpose of the keyboard shortcut and the panel is to select one of the x most recently selected tabs, where x is only a fraction of the number of all tabs. The list of all tabs is dealt with in bug 436304.

And all we're asking for is that 'x' be configurable (preferably with out having to restart Firefox). Unless I misunderstand the work that is being done, why is this being split up in to 2 separate features/implementations? It seems to me that you're writing your self in to a corner by providing 2 implementations for 2 specific cases. A dynamically configurable solution would cover both of the uses cases and allow for greater user control. Unless I fail to see the implications of what I'm saying, it seems like a much better solution to create a panel that can display an arbitrary number of tabs. Knowing the width and height of an individual tab preview takes and the width and height of the document window, it should be easy to calculate the maximum row length and count. If the number of tabs requests exceeds the row length, then additional rows are added. With that implemented, it could then be placed in different containers for either the Ctrl+Tab or All Tabs use cases. The context in which it is used would then control how many tabs were displayed. All Tabs: show as many tabs as possible Ctrl+Tab: show browser.ctrlTab.previewsCount or as many as possible, which ever is smaler

Sorry for the bug-spam... but I forgot to address the concerns of the original bug in my previous thoughts. when in Ctrl+Tab mode, it should be relatively easy to set the proper highlighted preview. If the list were constructed such that the first/most recent tab was first in the list, you could create a 'setOffset' function, which would be analogs to programmaticly cycling the list, a 'setIndex' which would set the selected index of the list, and 'setSticky' which would cause the list to cycle rather than the selected index. When the Ctrl+Tab mode had multiple rows (if the user so chose), it doesn't make sense for the middle of the row to be highlighted and 'sticky', so instead tabbing could change the selected index. When the user reached the end of the viewable list, the next viewable row could then be scrolled up part or all of the way to the top of the panel. The opposite would then happen when the user tabs off the top of the panel as well. Of course, this particular case could be avoided by changing my previously described Ctrl+Tab behavior to showing browser.ctrlTab.previewsCount tabs or one complete row, which ever is smaller.

(In reply to comment #7) > And all we're asking for is that 'x' be configurable (preferably with out > having to restart Firefox). Apparently your x and my x mean different things. I can go to the fourth tab in the MRU list without seeing four or even seven tabs at once. (Seven if you want to see four tabs ahead with the currently selected target in the middle, which is what this bug requests.) > Unless I misunderstand the work that is being done, why is this being split up > in to 2 separate features/implementations? It seems to me that you're writing > your self in to a corner by providing 2 implementations for 2 specific cases. I'm writing myself in a corner by providing different implementations for different use cases? I don't think this makes much sense. Surely this stuff could have been combined somehow, but there's no argument that this would cover the given use cases any better. > Unless I fail to see the implications of what I'm saying, it seems like a much > better solution to create a panel that can display an arbitrary number of tabs. > Knowing the width and height of an individual tab preview takes and the width > and height of the document window, it should be easy to calculate the maximum > row length and count. If the number of tabs requests exceeds the row length, > then additional rows are added. And if the rows don't fit the screen, the preview size is reduced. Yeah, see bug 436304. Being confronted with all tabs when using the keyboard shortcut for recently selected tabs doesn't seem useful but rather distracting. I don't even want to empower users to distract themselves with wrong pref settings. An extension could do that, though.

The problem I think we're having is that ideas on how this can be useful differ greatly. For you, a look-around of 1 is good enough for you, however I find it hard to use, especially when I'm quickly flipping though a bunch of tabs. Like I first said, as soon as I discovered this feature, the first thing I did was set browser.ctrlTab.previewsCount to 6. I find that much more usable and there is no way you can tell me that it isn't (as that is very much personal preference). This is why I'm advocating keeping (and fixing) the browser.ctrlTab.previewsCount preference. On a similar subject (Bug 445499), you seem to have the idea that MRU is the only useful ordering. For me it's, at best, an annoyance because that is not how I browse. Even with 20/30+ tabs open, I know where one is in relation to another, which makes for quick navigation. However having to search through a list which is ordered completely differently is almost completely useless. The very fact that Bug 445499 exists is a testament that others think so as well. My entire point is that by writing these features specifically for the limited use cases that you find useful, you are turning a potentially excellent feature in to something that will be useless to (probably) a fair number of users. From a design and implementation stand point, it doesn't make any sense to me either. You're creating potentially redundant code, which among other things, adds to the complexity of maintaining it. Conversely, by providing a uniform, centralized implementation, it makes it easier to adapt to multiple different uses. By adding/changing functionality to the core implementation, all of the implementations that depend upon it would then be able to leverage those changes as well. For example, as I purposed, having a central implementation that provided dynamic control over preview count and ordering would allow users to control those behaviors globally or on a per-implementation basis with out much additional work by the programmer. Thus a user would be able to independently control the ordering the the Ctrl+Tab and All Tabs in a way that works best for them (MRU, tab bar ordered, alphabetically, or any other way that is available). (In reply to comment #9) > Being confronted with all tabs when using the keyboard shortcut for > recently selected tabs doesn't seem useful but rather distracting. I don't even > want to empower users to distract themselves with wrong pref settings. An > extension could do that, though. That's all well and good, except that this the exact behavior that I, personally, want. And yes, while I could get an extension to do that, I have trouble justifying why I should if Firefox already provides the exact same functionality (sans the ability to control it). The kind of functionality we are asking for is trivial, yet behaviorally it has the power to make or break the feature. I just don't understand your reluctance to add/fix/keep these features aside from your own personal preference. I personally think this is a very dangerous way of thinking and I find it counterintuitive and in opposition to the very reason many of us use Firefox to begin with.

(In reply to comment #10) > On a similar subject (Bug 445499), you seem to have the idea that MRU is the > only useful ordering. For me it's, at best, an annoyance because that is not > how I browse. Even with 20/30+ tabs open, I know where one is in relation to > another, which makes for quick navigation. However having to search through a > list which is ordered completely differently is almost completely useless. The > very fact that Bug 445499 exists is a testament that others think so as well. Argue in bug 445499, then? If you disagree with MRU, there's currently no point in saying three previews aren't enough. Because right now, all that number is about is MRU previews. > From a design and implementation stand point, it doesn't make any sense to me > either. You're creating potentially redundant code, which among other things, > adds to the complexity of maintaining it. What's "potentially redundant"? Are you saying that if the UI would be more like what you're suggesting, we'd have redundant implementations? Alright. But that won't make me implement it your way. > Conversely, by providing a uniform, > centralized implementation, it makes it easier to adapt to multiple different > uses. By adding/changing functionality to the core implementation, all of the > implementations that depend upon it would then be able to leverage those > changes as well. Err, no, you're more flexible with specialized implementations, as you're free to implement just what each special case needs. What you're saying is only true if the different cases shared the same UI design, which is currently not the case and a highly debatable ground. That debate won't be about code but user experience. > > Being confronted with all tabs when using the keyboard shortcut for > > recently selected tabs doesn't seem useful but rather distracting. I don't even > > want to empower users to distract themselves with wrong pref settings. An > > extension could do that, though. > > That's all well and good, except that this the exact behavior that I, > personally, want. And yes, while I could get an extension to do that, I have > trouble justifying why I should if Firefox already provides the exact same > functionality (sans the ability to control it). Firefox could handle anything that's currently handled by extensions, including extensions that add ways to control Firefox features. But it doesn't, for reasons that I think are obvious. The important question is whether a higher preview count, a different order, etc. would be a better default configuration. I can't invest in adding and maintaining a load of prefs just to make you happy. Please don't try to convince me that it would be easier for me code wise, because it really isn't.

Ok, so this bug got side tracked so lets get back to the original idea, which is that if the user changes the number of visible items in the ctrltab list the selected item should be in the center. I'd prefer to see it that way simply because it looks more correct, less lopsided. Obviously if the user chooses an even number of items to show then there is no middle option, but that's their loss.

No idea if we should split up the look and feel for different platforms but running on OS X the application switcher is really nice. There is no bigger icon for the currently selected application but a white border is used instead. IMO this is more visible and perhaps less cpu consuming.

Theming would be a different bug.

Dao, by closing a bug as wontfix please give a comment why doing this. That would be really helpful to round-up the discussion. Thanks!

As of bug 456088, the previews are displayed in a grid, and the selection moves instead of the selected preview being scrolled into the view. Given that, there's no way this bug could be fixed.