Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Starred by 81 users
Status: WontFix
Owner:
Closed: Apr 2014
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Mac
Pri: 2
Type: Bug



Sign in to add a comment
Implement exposé for tabs
Project Member Reported by tha...@chromium.org, Jul 27 2010 Back to list
We want to experiment with an expose-for-tabs feature for chrome/mac. This is the tracking bug.

The feature will be behind a flag (--enable-expose-for-tabs).
 
Comment 1 by bugdro...@gmail.com, Jul 27 2010
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=53798 

------------------------------------------------------------------------
r53798 | thakis@chromium.org | 2010-07-27 10:18:23 -0700 (Tue, 27 Jul 2010) | 6 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.cc?r1=53798&r2=53797
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/common/chrome_switches.h?r1=53798&r2=53797

Mac: Add flag for expose-for-tabs

BUG= 50307 
TEST=none

Review URL: http://codereview.chromium.org/3020034
------------------------------------------------------------------------

Comment 2 by tha...@chromium.org, Jul 27 2010
Rough plan of attack is http://codereview.chromium.org/2976008 (not meant to be reviewed)
Comment 3 by bugdro...@gmail.com, Jul 27 2010
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=53833 

------------------------------------------------------------------------
r53833 | thakis@chromium.org | 2010-07-27 13:21:55 -0700 (Tue, 27 Jul 2010) | 9 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/app/chrome_dll_resource.h?r1=53833&r2=53832
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/app/generated_resources.grd?r1=53833&r2=53832
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/app/nibs/MainMenu.xib?r1=53833&r2=53832
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/app_controller_mac.h?r1=53833&r2=53832
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/app_controller_mac.mm?r1=53833&r2=53832
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/browser.cc?r1=53833&r2=53832

Mac: Add "Show Tab Overview" menu item.

xib changes: Add menu item with shortcut cmd-f10 for now, connect it to -commandDispatch:. Connect app controller's new outlet to the new menu item.

BUG= 50307 
TEST=No changes by default. If --enable-expose-for-tabs is passed, a new menu item should be visible below "prev tab" in the window menu. It should be active for normal browser windows and fullscreen windows, but not if there are no browser windows around or if the current window is a popup window or a non-browser window (e.g. prefs). Clicking the menu item doesn't do anything yet. cmd-f10 should trigger the menu item, but it shouldn't if the cmdline flag isn't passed.
TEST2=Go to a page that is busy spinning some javascript (e.g. "javascript:while(1);"), give it focus, hit cmd-f10. Menu should blink immediately.

Review URL: http://codereview.chromium.org/3020035
------------------------------------------------------------------------

Comment 5 by tha...@chromium.org, Jul 27 2010
Plan for the overlay window: It will be as large as web contents + info bars + detached bookmarks bar (on ntp), but shouldn't include download shelf and attached bookmarks bar.

Thumbs of pages with info bars and detached bookmarks bar should include both these bars. Ideally, per-tab sheets should be in the thumb too, but that's probably hard to do and not that important.

Comment 6 by tha...@chromium.org, Jul 27 2010
Open attached devtools should be handled like infobars.
Comment 7 by bugdro...@gmail.com, Jul 30 2010
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=54349 

------------------------------------------------------------------------
r54349 | thakis@chromium.org | 2010-07-30 11:32:35 -0700 (Fri, 30 Jul 2010) | 17 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/browser.cc?r1=54349&r2=54348
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/browser.h?r1=54349&r2=54348
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/browser_window.h?r1=54349&r2=54348
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/browser_window_cocoa.h?r1=54349&r2=54348
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/browser_window_cocoa.mm?r1=54349&r2=54348
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/browser_window_controller.h?r1=54349&r2=54348
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/browser_window_controller.mm?r1=54349&r2=54348
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/browser_window_controller_private.mm?r1=54349&r2=54348
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/tabpose_window.h
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/tabpose_window.mm
   A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/tabpose_window_unittest.mm
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_browser.gypi?r1=54349&r2=54348
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_tests.gypi?r1=54349&r2=54348
   M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/test/test_browser_window.h?r1=54349&r2=54348

Mac: Add tabpose window

The window doesn't have any contents yet, which makes its appearance look a bit janky for now.

BUG= 50307 
TEST=
* All the following happens only if --enable-expose-for-tabs is passed in, else all of it should be disabled.
* In a browser window, hit cmd-f10 or three-finger-swipe down. A grey overlay with a gradient at the top should appear.
* The overlay should cover tab contents, eventual info bars, the bookmarks bar if it's detached (but not the bookmarks bar if it's not detached), and eventual attached inspector windows. It should not cover the download shelf if it's open.
* The window should block clicks on the tab strip and the download shelf for now.
* The overlay should close on three-finger-swipe up, click, esc, enter, and space.
* Every open browser window should have its own overlay, and they should be independent of each other.
* If a browser window with an overlay window is active, most menu items should be greyed out, and all browser-related keyboard shortcuts should be disabled.
* In particular, hitting cmd-f10 twice should open only one overlay per browser window
* The overlay should have the correct size with a UI scale factor > 1

Review URL: http://codereview.chromium.org/2819070
------------------------------------------------------------------------

Comment 8 by thakis@google.com, Aug 9 2010
Stuff that's still missing:

* actual tab thumbnails (duh)
* favicon / title below the thumbs
* arrow keys should move selection
* selection needs to be highlighted somehow (outer blue border probably)
* currently selected tab should redraw live?
* mouse cursor should become a hand while tabpose is active (? 10.5 does this, 10.6 doesn't – so we probably don't want this)
Comment 9 by thakis@google.com, Aug 10 2010
* Need a TabStripObserver to check that the tabstrip doesn't change from below us.
Comment 10 by thakis@google.com, Aug 11 2010
Not-ready-for-review CL for tab thumbnails is at http://codereview.chromium.org/3163003. Favicon/title and the blue selection rect are already in. (r55643 and r 55505)
Why not have the 3 fingers swipe left / right and leave the up / down to Home / End (32069) ?
As stated in the other topic 3 fingers fingers left/right already in use in a very common touchpad gesture. 3 fingers u/d for tabs expose is a great idea, and there is no other available touch gesture that could be assigned to. And it shouldn't be buried for home/end which could be added also, given a customization option.
 Issue 51923  has been merged into this issue.
Comment 14 Deleted
Comment 15 by pdknsk@gmail.com, Aug 29 2010
I'm not familiar with Mac, but does this need Exposé to work or is it like Firefox Panorama? In the latter case are there any plans to have this for Linux and Windows also?

Comment 16 by thakis@google.com, Aug 29 2010
pdknsk: It's not even sure we'll do this on mac…it's just an experiment for now, and about:labs is only available in the dev and beta channels. Experiments are automatically disabled on the stable channel.

If we decide to keep it on mac, we'll then discuss if it's useful on windows and linux too (maybe it's better to use the "native" overview mode on these platforms – i.e. vista's windows-tab window cycling view on windows and whatever linux does these days on linux?).
Even though is still an experiment there is something you may find useful to add. 
On OSX expose
* 4 fingers down -> tab display and then,
* 4 fingers up or down on a tab -> tab choice

while on chromium tabpose
* 3 fingers down -> tab display and then,
* 3 fingers (only) up on a tab -> tab choice

I think you should consider to give 3 fingers up or down on a tab in order to choose it, it would feel even more familiar to us. Tabpose is a great addition, keep on!
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=58951

------------------------------------------------------------------------
r58951 | thakis@chromium.org | Thu Sep 09 10:16:12 PDT 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/app/nibs/MainMenu.xib?r1=58951&r2=58950&pathrev=58951

Mac: change tabpose shortcut to cmd-ctrl-t (matches camino)

BUG= 50307 

Review URL: http://codereview.chromium.org/3337019
------------------------------------------------------------------------
Labels: -Mstone-7 Mstone-8
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=59099

------------------------------------------------------------------------
r59099 | thakis@chromium.org | Fri Sep 10 08:55:53 PDT 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/branches/517/src/chrome/app/nibs/MainMenu.xib?r1=59099&r2=59098&pathrev=59099

Merge 58951 - Mac: change tabpose shortcut to cmd-ctrl-t (matches camino)

BUG= 50307 

Review URL: http://codereview.chromium.org/3337019

TBR=thakis@chromium.org
Review URL: http://codereview.chromium.org/3367023
------------------------------------------------------------------------
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=59703

------------------------------------------------------------------------
r59703 | thakis@chromium.org | Thu Sep 16 13:10:53 PDT 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/cocoa/tabpose_window.mm?r1=59703&r2=59702&pathrev=59703

Mac: Add a few more keyboard shortcuts to tabpose.

* shift / tab-shift cycle through all open tabs
* arrow keys move selection up, down, left, right
* cmd-1-8 selects tab 1-8 and exits tabpose, cmd-9 selects last tab and exits tabpose
* cmd-ctrl-t exits tabpose

BUG= 50307 , 55530 
TEST=try it

Review URL: http://codereview.chromium.org/3389010
------------------------------------------------------------------------
Labels: -mstone-8 Mstone-X
Comment 24 by mark@chromium.org, Sep 29 2010
Suggestions!

1. The omnibar or whole toolbar needs to be disabled, or dimmed, or something when Tab Pose is active.

2. It'd be cool if there were some sort of feedback like “hover thumbnail, highlight tab” and vice-versa.

3. If it would fire for a triple-swipe on a background window, that’d be cool.
Comment 25 by alcor@google.com, Oct 1 2010
Laundry list:

* omnibox should work on this page, either acting as a new spawn, or clobbering the last used page. Depending on this, we should hide or show the current url. I'd probably favor clobbering since the tab is still atached. Command L and Command T should work

* close boxes

* text labels appear to be drawing on pixel borders. they are fuzzy.

* text labels should be visible during animate in. 

* anything we can do to fix interpolation would be great.


* two finger scrolling should work to move them around, maybe also to select
Comment 26 by till...@gmail.com, Oct 1 2010
I notice that the scroll bar appears in the thumbnail. Is this intentional? 
Comment 27 by thakis@google.com, Oct 1 2010
Tills13: You mean the scrollbar on the right? Yes, that's intentional. Why do you think it shouldn't be there?
Comment 28 by till...@gmail.com, Oct 1 2010
To me, the focus is on the content of the page in its current condition (regardless of your position on that page). The objective of Tabposé is to allow for people to quickly switch between tabs with some accuracy and some indication about what's on that page - the addition of the scrollbar just seems a bit unnecessary. 

I'd also like to discuss a design point. Currently, the more windows you have, the smaller the thumbnails get. Wouldn't it be more pertinent to keep it to, say, three thumbnails per row and allow for scrolling? 

Screenshot one is what it should always be and screenshot two is what happens currently. 
Screen shot 2010-10-01 at 2.03.21 PM.png
207 KB View Download
Screen shot 2010-10-01 at 2.03.49 PM.png
150 KB View Download
Comment 29 by studi...@gmail.com, Oct 19 2010
@thakis:

Clicking on a tab immediately after entering Tab Overview (without moving the mouse) should select that tab, rather than returning to the currently selected tab.

While fixing this, there should be some difference of indicator between the hovered/focused tab (which would be selected upon click/enter key) and the currently selected tab.

Thanks for your work on this.
Is this feature disabled on windows ?
If yes, why ?
I like this feature and i want to use it in windows
Right now this is a Mac-only experiment.
Comment 32 by till...@gmail.com, Nov 3 2010
This should be promoted to a feature; it not an experiment. 
Comment 33 by gord...@gmail.com, Dec 6 2010
Could we have a file menu item for tabpose?  In OS X, this allows us to use the keyboard preference pane to reassign the keyboard shortcuts.
Comment 34 by thakis@google.com, Dec 6 2010
comment 33: It's there already: Window->Show Tab Overview…
Comment 35 by gord...@gmail.com, Dec 6 2010
Sorry about missing that, thanks!
Project Member Comment 36 by bugdroid1@chromium.org, Dec 8 2010
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=68610

------------------------------------------------------------------------
r68610 | thakis@chromium.org | Wed Dec 08 10:25:22 PST 2010

Changed paths:
 A http://src.chromium.org/viewvc/chrome/trunk/src/gfx/scoped_cg_context_state_mac.h?r1=68610&r2=68609&pathrev=68610
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/tabpose_window.mm?r1=68610&r2=68609&pathrev=68610
 M http://src.chromium.org/viewvc/chrome/trunk/src/gfx/gfx.gyp?r1=68610&r2=68609&pathrev=68610

Mac: Use high-quality interpolation to draw tabpose thumbnails.

BUG= 50307 , 65894 
TEST=Activate tabpose, thumbnails should look nicer, but the feature shouldn't be visibly slower.

Review URL: http://codereview.chromium.org/5526011
------------------------------------------------------------------------
Project Member Comment 37 by bugdroid1@chromium.org, Dec 9 2010
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=68753

------------------------------------------------------------------------
r68753 | thakis@chromium.org | Thu Dec 09 11:07:00 PST 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/tabpose_window.mm?r1=68753&r2=68752&pathrev=68753

Mac: Align tabpose titles on pixel boundaries, making them less blurry.

Also align favicon and title at their vertical center instead of at the baseline to match the tab look.

BUG= 50307 
TEST=Open tabpose. Titles shouldn't be blurry.

Review URL: http://codereview.chromium.org/5729001
------------------------------------------------------------------------
Project Member Comment 38 by bugdroid1@chromium.org, Dec 9 2010
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=68787

------------------------------------------------------------------------
r68787 | thakis@chromium.org | Thu Dec 09 15:19:27 PST 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/tabpose_window.mm?r1=68787&r2=68786&pathrev=68787

Mac: make favicon and title visible during in/out animation.

BUG= 50307 
TEST=Look.

Review URL: http://codereview.chromium.org/5618007
------------------------------------------------------------------------
Project Member Comment 39 by bugdroid1@chromium.org, Dec 15 2010
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=69323

------------------------------------------------------------------------
r69323 | thakis@chromium.org | Wed Dec 15 13:48:33 PST 2010

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/tabpose_window.mm?r1=69323&r2=69322&pathrev=69323

Mac: zoom title and favicon during tabpose zoom animation

BUG= 50307 
TEST=Zoom out in slomo. Favicon and tab titles should fly in like the thumbnails. Zoom back in, they should still look correct.

Review URL: http://codereview.chromium.org/5764002
------------------------------------------------------------------------
Some suggestions for the future of this experiment:
 - Make tabs closeable from overview. This would require the thumbnails to animate to new positions, but it seems like you guys implemented that already. Briefly, I could close tabs whilst in overview (using cmd-W), but that bug was killed pretty quick (or I have been unable to repro it)
 - drag thumbnail to create a new 
Comment 41 by till...@gmail.com, Dec 18 2010
I think you cut off there, Balasan. 

However, I definitely agree with your first point. Even if Exposé for Mac doesn't allow for the closing/managing of applications, perhaps this would be a good time to branch from that and start to reference it instead of copying it. 

I'd like to bring up Comment #28, again. There should be a width/horizontal items limit... More aesthetically pleasing/easier to use. 
Project Member Comment 42 by bugdroid1@chromium.org, Jan 12 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=71208

------------------------------------------------------------------------
r71208 | thakis@chromium.org | Wed Jan 12 11:08:26 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/skia/ext/skia_utils_mac.mm?r1=71208&r2=71207&pathrev=71208
 M http://src.chromium.org/viewvc/chrome/trunk/src/skia/ext/skia_utils_mac.h?r1=71208&r2=71207&pathrev=71208
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/tab_strip_controller.mm?r1=71208&r2=71207&pathrev=71208
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/tabpose_window.mm?r1=71208&r2=71207&pathrev=71208

Mac: Explicitly set the colorspace on SkBitmap -> CGImageRef conversions.

The color space was hardcoded as "generic rgb" in skia. This is not always correct, also skia is changing this color space around a lot currently. To protect us from their unreliable default, hardcode "generic rgb" as default on our side for now, but make it possible for clients to provide their own color space.

Use this to let tabpose and the favicon code pass in the device colorspace.

BUG=24267, 50307 
TEST=Open tabpose. Delayed thumbnails should look like backing-store backed thumbnails. The colors of favicons should now match other browsers.

Review URL: http://codereview.chromium.org/6117006
------------------------------------------------------------------------
Project Member Comment 43 by bugdroid1@chromium.org, Jan 12 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=71232

------------------------------------------------------------------------
r71232 | thakis@chromium.org | Wed Jan 12 13:03:02 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/app/theme/theme_resources.grd?r1=71232&r2=71231&pathrev=71232
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/tabpose_window.mm?r1=71232&r2=71231&pathrev=71232
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/tabpose_window.h?r1=71232&r2=71231&pathrev=71232

Make thumbnails closable in tabpose

Also make the thumbnails left-aligned. The reason for this is that when thumbnails are closed, the reshuffling algorithm looks a bit busy. We want to eventually slide thumbs out on the left side on the window and then slide them back in from the right.

BUG= 50307 
TEST=
* Hover a thumb. It should show a close button.
* Press opt. All thumbs should show a close button.
* Press a close button. Thumb should close, the rest of the tabs should reshuffle.

Review URL: http://codereview.chromium.org/5960008
------------------------------------------------------------------------
Comment 44 by thakis@google.com, Jan 12 2011
balasan, TIlls: I added a first cut at close buttons. I'm not convinced that an overview mode should have a scrollbar, though :-)
Comment 45 by till...@gmail.com, Jan 12 2011
Google seems like to scrollable "walls" of thumbnails (I'm talking about Honeycomb), borrowing a page from the Android team's book wouldn't hurt anyone. 

Other than that, is there any way around shrinking the thumbnails when more than, say, nine tabs are open?
Nico, here are some thoughts on the last changes:

-> The tab should close after a Click_&_Release. At the moment it closes just with a click. 

-> It would be great, if we could create the closed tab(s) with the official shortcut SHIFT-CMD-T within the overview back. With a nice animation of course ;-)

Thanks
Mehmet
Might be a little far out now but maybe to close you can click the tab, shake it while still holding the left mouse button and let go. Like "shake" in Windows 7...
I'm not sure about scrollbars in overview mode either.

I really like the idea for reopen close tab, and click & release sounds good too.

I was wondering, is there a technical reason the window buttons (ie minimize, close, and the weird third button) have to be disabled while in tab overview? Are you spoofing the overview mode by creating an overlay window?

Btw, weird corner case, when you go into tab overview mode, the address bar are disabled, which is appropriate behaviour. Typing into the address bar when in overview mode doesn't really make sense.

However if go into overview mode, then choose Chrome->About Google Chrome (in the menu bar), then close the about window, by default the about window chooses the window that launched it and reenables the address bar and the window management buttons. If you had focus in the address bar before you went into tab overview mode you will be able to type into the address bar again (and you're not really sure which tab you're typing into). You're also able to ctrl-tab your way through selected tabs,create new tabs with cmd-T, and close tabs with cmd-W. I have my prefs open in a tab and that has a similar result. While in this odd state, you can also minimize windows which behaves rather strangely.
umm, this is isn't really a huge deal, just a bit of ui weirdness.

I just downloaded and built the chromium source, so maybe if I can get familiar enough with the areas involved, I can try fixing some of the things mentioned.

Sanjay
Comment 51 by till...@gmail.com, Feb 18 2011
in tab overview, could we have the omnibox serve as a search box for the tabs? If the keyword is found on any of the tabs, it's highlighted in yellow or something, and as soon as the term or phrase is *not* found, the thumbnail preview darkens.  
Is there any plan to make the tab overview gesture configurable, because I've been triggering it accidentally recently and would prefer to be able to disable it? I use jitouch to add a bunch of gestures to the multitouch MBP trackpad. One of those gestures is for closing the current window, which involves putting one finger down on the trackpad and then dragging two fingers down to the right of that finger. Frequently, tab overview gets activated accidentally when I perform the gesture. I suspect that I'm probably moving the fixed finger a little bit and that's triggering the gesture recognizer, but it's a bit too touchy not to accidentally trigger on a regular basis.
comment 52: see issue 73638 for the jitouch interaction.
Comment 54 Deleted
Comment 55 Deleted
Would there be any possibility of changing the three-finger-swipe down gesture for this feature to three-finger-tap?  The tap gesture isn't currently used, and it would open up the three-finger-swipes for the many requests in  Issue 32069  to implement top/bottom of page for the swipe gestures.



I use the three finger tap for middle button click (open link in new tab). With Lion coming out soon and the potential for Apple to change/add new gestures, it seems like assuming that some gesture is "open" is going to cause a lot of problems for users. With programs like jitouch, it seems like the best thing to do with gestures is to make it possible for all of them to be disabled, and to provide menu items or keyboard shortcuts for users to trigger them from a global gesture recognizer (like jitouch) if they want to under a different gesture.

It would be really cool if Apple created a global gesture subscription service so that this wasn't an issue, but from what I understand, that's not currently the case. 
Project Member Comment 58 by bugdroid1@chromium.org, Mar 8 2011
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=77227

------------------------------------------------------------------------
r77227 | thakis@chromium.org | Mon Mar 07 17:50:00 PST 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/tabpose_window.mm?r1=77227&r2=77226&pathrev=77227
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/tabpose_window.h?r1=77227&r2=77226&pathrev=77227

mac: UI tweaks to tab overview mode

BUG= 50307 
TEST=tab overview mode looks different

Review URL: http://codereview.chromium.org/6621056
------------------------------------------------------------------------
Dragging a tab into a window in tabpose mode occasionally fails. Seems like it fails if you drag it into the very left of the tab bar, and the tabpose layout is changing (ie the number of rows/columns). This usually works at creating some weird layouts, take a look at attached screenshots.

Also, if you drag tabs in, the order of thumbnails is messed up, ie you drag a tab in, click on a thumbnail, it zooms in with that thumbail, then as soon as the animation completes switches to the actual page that you clicked on.
Screen shot 2011-03-08 at 10.15.01 PM.png
1.4 MB View Download
Screen shot 2011-03-08 at 10.16.21 PM.png
1.2 MB View Download
Looks like tabpose doesn't trigger repaints. I.e., start loading a page in a tab, and quickly switch to another tab. Wait for the page to finish loading. Trigger tabpose, and see that the tab thumbnail still shows whatever was the last paint you saw, and not what is actually possible now (if that tab were to be repainted).

I think one of the key uses of tabpose will be to quickly see if some tab has been updated (say sports scores, finance gadgets, games, videos, other animations, or even just some slow loading pages). We should repaint tab thumbnails if possible.
sreeram: There'a a TODO for that in the code :-) There's a notification when the page changes, but it fires a lot during loads. So we need to make sure we repaint at most every 5 seconds or so (e.g. let a load event start a 5s timer, ignore all load events in that time span, and then ask for a repaint when the timer fires). CLs welcome :-)
Comment 62 by hinch...@gmail.com, Mar 11 2011
"Would there be any possibility of changing the three-finger-swipe down gesture for this feature to three-finger-tap?  The tap gesture isn't currently used, and it would open up the three-finger-swipes for the many requests in  Issue 32069  to implement top/bottom of page for the swipe gestures."

Agree there's likely to be significant collision issues if gestures can't be modified/disabled. Tabpose on 3 finger swipe down doesn't seem necessary since it's already a menu item /w key shortcut... and most switchers from Firefox will expect the end of page behavior. 

Moving tabpose to a 3 finger tap seems a good compromise, then moving 3 finger swipe up/down to home/end helps attract current Firefox users unwilling to switch to Chrome because this is missing (seems to be quite a few, I personally know more of those people than I do any actually using tabpose).


Project Member Comment 64 by bugdroid1@chromium.org, Mar 18 2011
Whats the ETA on this feature for windows ?

I did notice you have started the working on this so here's some inspiration:
(Firefox Panorama: How To)
http://vimeo.com/14364400

Note: if you follow the link you will also find more videos about tab management :)

Hope it helps
Note that using three finger tap might conflict with the three finger double-tap used for dictionary lookups ( Issue 92006 )
Any news on this old one?
Project Member Comment 68 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-UI Cr-UI
Labels: M-34
Status: WontFix
We ended up removing the feature in r251439 (some discussion in  https://codereview.chromium.org/154083008/).

The reasons for this include some combination of us thinking the feature being pretty nifty but not world-changing, the thumbnail code making changes to the accelerated paiting pipeline harder, and os x 10.7 using three-finger-swipes for os-related things.
Sign in to add a comment