Let's provide better support for people who like browsing with the tab sidebar open, and for those who prefer to keep it closed. New behaviour: * By default, that tab tray should not be pinned open. Opening the tray should slide the content view to the right (not scale it), and then close as soon as a new tab is opened or selected. * When the tray is pinned open, the content area should be resized to this smaller view. Mockup for pinned tab tray: http://cl.ly/image/0q2J2l1P1B32 Mockup for unpinned tab tray: http://cl.ly/image/3X0q3i2w230o Note that the pinned tray has a slightly different design: The Firefox tab curve is removed, to simplify the sidebar UI for people who will always be looking at it. This will also make scrolling the header off the screen look better, by providing better visual separation between the tab and content area.

I was pretty happy with the tabs pane open in my tablet until the last update to version 23. Then it took me a while to find that there is a button in the top left for opening the tabs pane. Then after choosing one tab and touching the screen, there goes the tabs pane again. Sigh. A one-tap process now requires 2 or 3 taps. And there is no option anywhere for getting back the old behaviour. Come on, folks, this is not usability, this is not making things easier or more simple to the average user. I found a Google Groups post with a lot of people coomplaining about a similar feature which was implemented to Chrome. Why must Firefox, regarded as the most configurable and customizable browser available, follow the same path?? I have no solution or more data to post here, but I would just like to add my disappointment about this UI decision and reinforce the request for a pinning option for the tabs pane. Thank you and best regards!

(In reply to Fabricio Rocha from comment #2) > I was pretty happy with the tabs pane open in my tablet until the last > update to version 23. Then it took me a while to find that there is a button > in the top left for opening the tabs pane. Then after choosing one tab and > touching the screen, there goes the tabs pane again. Sigh. > > A one-tap process now requires 2 or 3 taps. And there is no option anywhere > for getting back the old behaviour. Come on, folks, this is not usability, > this is not making things easier or more simple to the average user. I found > a Google Groups post with a lot of people coomplaining about a similar > feature which was implemented to Chrome. Why must Firefox, regarded as the > most configurable and customizable browser available, follow the same path?? > > I have no solution or more data to post here, but I would just like to add > my disappointment about this UI decision and reinforce the request for a > pinning option for the tabs pane. Thank you and best regards! We may be talking about the same people that want to force us to use Tabs On Top.

On desktop Firefox that is.

Will, that is not a helpful comment, nor is it in any way related to Firefox for Android. The purpose of this bug is to do the very thing Fabricio is asking for. We had to cut it for the sake of landing a larger set of tab UI refinements on tablets, and we fully intend to add it as soon as we can. We want it too! :)

This works pretty well. Adds a button next to the "New tab" one that pins the sidebar. I'll post a screenshot. I originally added an interface here that took a few parameters: onPinned(boolean, int, int); thinking that callers might need that info. We actually don't need any of it though (BrowserApp already has a reference to the tabs panel to get at this), and it turned out easier to just call into functions that already exist. I left the parameters in here, because I kinda do feel like a good interface should pass them to you, but I don't have strong feelings about it. Also, I keep running into issues when I want to deal with the tabs tray, because we don't have good ways to just make the views VISIBLE (and existent :) ), without triggering a cascade of notifications and animations. I think we need to fix that. Curious if you've got any good ideas lucas? I took some liberties with UI, reusing a lock image that's already in the tree. Its placeholder, but I'll attach a screenshot.

Comment on attachment 797100 [details] screenshot Why keep the area for the button that opens the tab list when the tab list is pinned? I would prefer to have more room for the URL bar.

Comment on attachment 797099 [details] [diff] [review] Patch Review of attachment 797099 [details] [diff] [review]: ----------------------------------------------------------------- Looks good overall. ::: mobile/android/base/BrowserApp.java @@ +578,5 @@ > + ThreadUtils.postToBackgroundThread(new Runnable() { > + @Override > + public synchronized void run() { > + SharedPreferences settings = getPreferences(Activity.MODE_PRIVATE); > + settings.edit().putBoolean(STATE_SIDEBAR_PINNED, mTabsPanel.isPinned()).commit(); Not sure it's safe to run this in a bg thread inside onPause as is. For instance, mTabsPanel might be about to be destroyed. Maybe fetch isPinned() into a final boolean then use it here? @@ +1267,5 @@ > if (hasTabsSideBar()) { > + // We shouldn't be animating the sidebar open and closed if we're pinned, > + // but since there is (currently) no other way to show it, we do attempt to > + // animate it during startup. Just animate to scroll 0, since the margin will offset > + // the tabs panel for us. Maybe use time = 1 so that the tabs panel simply snaps on startup?

(In reply to Wesley Johnston (:wesj) from comment #6) > Also, I keep running into issues when I want to deal with the tabs tray, > because we don't have good ways to just make the views VISIBLE (and existent > :) ), without triggering a cascade of notifications and animations. I think > we need to fix that. Curious if you've got any good ideas lucas? Ideally, the code to show/hide the tabs panel should be the same when simply snapping it on screen. Not always possible though. I had to do something like this on the toolbar (see setUrlEditContainerVisibility). But that's a simple case because it only involves visibility, no position/size changes. The most obvious option I guess is to have to code paths: one with PropertyAnimators (for the animated case) and another with just ViewHelper.set* and scrollTo calls.

This is some polish (probably for a different bug) to animate the urlbar icons in/out when the urlbar is pinned. Its also got some cleanup to move some of this animation logic into more reusable functions. I'm using a "pass null to do this instantaneously, or an Animator to animate it" trick that I like, but will need to clean up. Putting it here so its saved somewhere. There's still some jank as the content area/about:home resizes itself that will be fairly difficult to smooth out. web content we should be able to just do a straight scale to... about:home would be fairly difficult (since text sizes remain the same while their containing boxes change size).

filter on [mass-p5]

I don't think this bug applies anymore since we don't have a "side bar" so much as a tabs "tray" now.