Present, and Future of mini-tabs (App tabs, Pinned tabs, and phantom tabs)
username at localhost
A mini tab is any tab that only shows a favicon.
A phantom tab is a tab that does not have a corresponding rendering
engine instance.
An app tab is a mini tab associated with an extension.
I believe these definitions are equivalent to the current usage of
the terms in the source. If there are any notable differences I would
love to hear them.
- - - - -
In this section I will describe the history of these features in
Chromium as well as I have managed to piece them together. Please feel
free to correct me here if I am making any mistakes.
The first mini tab to exist was the Pinned tab. When this tab was
first developed there was talk about it having all external links open
in a new tab, making them function much like the abstract concept of
an Application tab. As far as I can tell, that functionality was never
implemented, but the address bar had similar functionality added.
Specifically, in a pinned tab, one could change the URL to another
page on the same site, and that page would open in the pinned tab, but
type a URL for a different page, and that would be opened in a new
tab.
Then along comes the idea of an app tab. For regular chromium, an app
tab is a mini tab that has an underlying chromium extension. The
extension specifies the main page of the webapp. It might also have
other behavior, such as background polling the webapp, to allow it to
change the app tab's (or corresponding phantom tab's) favicon to
indicate unread messages, among many other possibilities.
Unlike pinned tabs, app tabs have no option to unpin them. I am not
sure if there is currently any way to quickly distinguish them from
pinned tabs, except by trying to unpin them. There was some talk about
letting app tabs have larger icons, although scaling favicons does not
generally look good, so I don't believe that is implemented. I am
uncertain if it has been implemented, but app tabs should have all
external links open in a new tab, much like what was once planned for
pinned tabs.
App tabs were implemented utilizing the existing code for pinned tabs.
As a result, while the code was being developed, for a short while
pinned tabs were not available. this caused some level of outcry.
However pinned tabs have since been restored, although the ability to
pin and unpin them by dragging the tabs has since been removed, and as
far as I can tell, there are currently no plans to restore this, since
the behavior was actually surprising.
Unlike the plan for ChromiumOS it appears that an app launcher is not
planned for Chromium. As a result, there needs to be some way to
reopen apps that have been closed. To this end phantom tabs were
invented. Phantom tabs have no rendering engine attached, and unlike
other forms of tabs, they do not prevent the window from closing. When
an app tab is closed it becomes a phantom tab. When a phantom tab
corresponding to an app tab is clicked, it is converted into a full
app tab, with the main page of the app (as specified by the Chromium
extension) being the displayed page. Currently phantom tabs can be
visually distinguished by being less opaque than other mini tabs.
Now, as a result of code sharing, currently pinned tabs have inherited
pretty much all the behavior of app tabs, except that they can be
unpinned. A second difference is that since they don't have an
underlying extension, they have no app default page, so phantom tabs
for pinned tabs return to the page the pinned tab was last viewing
when clicked. But overall, currently, pinned tabs function as app tabs
lite.
Now there is one other feature of app tabs and app tabs lite that I
have not touched on. These tabs are remembered an restored regardless
of whether the browser is set to restore tabs when reopened. this
behavior may seem a bit surprising, but it makes good sense. It is
strictly necessary to remember app tabs since they have a
corresponding extension, and could thus be recreated by iterating
though the extensions; however, by remembering them, other things like
the ordering of the tabs the user chose are also remembered. This
would also be the only way of remembering any app tabs lite. It makes
perfect sense then to remember them even if the setting to remember
tabs is not set.
The full logic for that has not be implemented as indicated by Issue
43509, which notes that phantom tabs are restored as app tabs (lite)
upon reopening the browser. The logical behavior here would vary upon
whether the setting to restore tabs is set. If it is set, the tabs
should be restored in the state they were in when closed. If the
restore tabs setting is not set, then logically app tabs and app tabs
lite should be restored as phantom tabs, and a regular tab should be
opened and have focus (with the new tab page or homepage as
applicable).
That concludes by summary of the history, which also implicitly
details the current state of mini tabs. I am not completely confident
in the state of app tabs as opposed to app tabs lite, since I don't
have any extensions that create app tabs.
- - - - -
Now some questions and ideas about the present and future of mini
tabs.
What is the plan for pinned tabs? Will they be kept as app tabs lite,
or will they have different functionality? Either way, the url bar and
links on the page should treat external sites the same, shouldn't
they?
Has the code to have external links for app tabs open in a new tab
been implemented?
Has it been documented how to create an extension hat makes an app
tab? If so where? If not, when is this going to be documented?
Phantom tabs are distinguishable by the reduced opacity, although at
least with the default skin they can be rather difficult to
distinguish from regular mini tabs. Are there any plans to rectify
this? One possibility that sounds good to me, is to leave the favicon
fully opaque, but turn the opacity of the tab itself all the way down
to being completely transparent. the result is that phantom tabs look
like just icons floating in the tabbar. That makes them easy to
distinguish from other mini tabs. Furthermore, they would not actually
look like tabs, which would make why the window can close even with
them still there seem more intuitive. Thoughts?
- - - - -
I do look forward to the point where the app tab features are finished
and available in chrome, so I can have extensions that create app tabs
for some of frequently used webapps, especially GMail and Google
calendar.
Peter Kasting
The first mini tab to exist was the Pinned tab. When this tab was
first developed there was talk about it having all external links open
in a new tab, making them function much like the abstract concept of
an Application tab. As far as I can tell, that functionality was never
implemented, but the address bar had similar functionality added.
Specifically, in a pinned tab, one could change the URL to another
page on the same site, and that page would open in the pinned tab, but
type a URL for a different page, and that would be opened in a new
tab.
Unlike pinned tabs, app tabs have no option to unpin them. I am not
sure if there is currently any way to quickly distinguish them from
pinned tabs, except by trying to unpin them.
Unlike the plan for ChromiumOS it appears that an app launcher is not
planned for Chromium.
The logical behavior here would vary upon
whether the setting to restore tabs is set. If it is set, the tabs
should be restored in the state they were in when closed. If the
restore tabs setting is not set, then logically app tabs and app tabs
lite should be restored as phantom tabs, and a regular tab should be
opened and have focus (with the new tab page or homepage as
applicable).
Scott Violet
It's actually a bit more subtle than that. There are two variants of these:
. You install an app and it opens an app tab. These are visually
rendered differently than pinned tabs and in view code are called
nano-tabs.
. If you have installed an app and you navigate to a page that falls
under the extent of an extension, then the tab gets currently gets the
bigger icon. This type of tab is not rendered as a mini or nano tab
though, and we may not make it get the bigger icon at some point.
> The
> extension specifies the main page of the webapp. It might also have
> other behavior, such as background polling the webapp, to allow it to
> change the app tab's (or corresponding phantom tab's) favicon to
> indicate unread messages, among many other possibilities.
>
> Unlike pinned tabs, app tabs have no option to unpin them.
You can pin/unpin these tabs, but they always visually render the
same. A pinned app tabs goes phantom when you close it, where as an
unpinned app tab closes when you close it.
> I am not
> sure if there is currently any way to quickly distinguish them from
> pinned tabs, except by trying to unpin them. There was some talk about
> letting app tabs have larger icons, although scaling favicons does not
> generally look good, so I don't believe that is implemented. I am
> uncertain if it has been implemented, but app tabs should have all
> external links open in a new tab, much like what was once planned for
> pinned tabs.
They can specify a bigger icon (24x24, SMALLISH (yes, it's an awful name)).
> App tabs were implemented utilizing the existing code for pinned tabs.
> As a result, while the code was being developed, for a short while
> pinned tabs were not available. this caused some level of outcry.
The feature was removed for different reasons.
> However pinned tabs have since been restored, although the ability to
> pin and unpin them by dragging the tabs has since been removed, and as
> far as I can tell, there are currently no plans to restore this, since
> the behavior was actually surprising.
Yes, that's right.
> Unlike the plan for ChromiumOS it appears that an app launcher is not
> planned for Chromium. As a result, there needs to be some way to
> reopen apps that have been closed. To this end phantom tabs were
> invented.
Phantom tabs were added to allow you to reserve real estate for
frequently used tabs while at the same time freeing up resources.
> Phantom tabs have no rendering engine attached, and unlike
> other forms of tabs, they do not prevent the window from closing. When
> an app tab is closed it becomes a phantom tab. When a phantom tab
> corresponding to an app tab is clicked, it is converted into a full
> app tab, with the main page of the app (as specified by the Chromium
> extension) being the displayed page. Currently phantom tabs can be
> visually distinguished by being less opaque than other mini tabs.
>
> Now, as a result of code sharing, currently pinned tabs have inherited
> pretty much all the behavior of app tabs, except that they can be
> unpinned.
You can also pin/unpin app tabs, but it gives slightly different behavior.
We are experimenting with other differences. For example, app tabs
might hide the toolbar completely.
> Either way, the url bar and
> links on the page should treat external sites the same, shouldn't
> they?
>
> Has the code to have external links for app tabs open in a new tab
> been implemented?
These are still up in the air.
> Has it been documented how to create an extension hat makes an app
> tab? If so where? If not, when is this going to be documented?
Not sure. Perhaps one of the extensions guys can comment.
> Phantom tabs are distinguishable by the reduced opacity, although at
> least with the default skin they can be rather difficult to
> distinguish from regular mini tabs. Are there any plans to rectify
> this? One possibility that sounds good to me, is to leave the favicon
> fully opaque, but turn the opacity of the tab itself all the way down
> to being completely transparent. the result is that phantom tabs look
> like just icons floating in the tabbar. That makes them easy to
> distinguish from other mini tabs. Furthermore, they would not actually
> look like tabs, which would make why the window can close even with
> them still there seem more intuitive. Thoughts?
We've tried different things. I believe most folks are happy with the
current look.
-Scott
> - - - - -
>
> I do look forward to the point where the app tab features are finished
> and available in chrome, so I can have extensions that create app tabs
> for some of frequently used webapps, especially GMail and Google
> calendar.
>
> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev
>
Aaron Boodman
>> Has it been documented how to create an extension hat makes an app
>> tab? If so where? If not, when is this going to be documented?
>
> Not sure. Perhaps one of the extensions guys can comment.
http://code.google.com/chrome/apps/docs/developers_guide.html
- a
username at localhost
tabs.
It mentions two types of tabs that are implicitly mini tabs. Pinned
tabs, and application tabs.
Are you talking about code not yet present in the public source
repository?
>
> > The
> > extension specifies the main page of the webapp. It might also have
> > other behavior, such as background polling the webapp, to allow it to
> > change the app tab's (or corresponding phantom tab's) favicon to
> > indicate unread messages, among many other possibilities.
>
> > Unlike pinned tabs, app tabs have no option to unpin them.
>
> You can pin/unpin these tabs, but they always visually render the
> same. A pinned app tabs goes phantom when you close it, where as an
> unpinned app tab closes when you close it.
There are two orthogonal concepts.
One is whether an tab is an app tab (in the mini tab sense), the other
is if the tab is pinned.
If either of those are true, the tab is a mini tab (in the sense used
by the tabstrip code.)
It is pinned tabs that go phantom, and pinned tabs that are restored
on starup, but those may be regular tabs, or app tabs.
Got that.
> > I am not
> > sure if there is currently any way to quickly distinguish them from
> > pinned tabs, except by trying to unpin them. There was some talk about
> > letting app tabs have larger icons, although scaling favicons does not
> > generally look good, so I don't believe that is implemented. I am
> > uncertain if it has been implemented, but app tabs should have all
> > external links open in a new tab, much like what was once planned for
> > pinned tabs.
>
> They can specify a bigger icon (24x24, SMALLISH (yes, it's an awful name)).
of the extension?
>
> > Unlike the plan for ChromiumOS it appears that an app launcher is not
> > planned for Chromium. As a result, there needs to be some way to
> > reopen apps that have been closed. To this end phantom tabs were
> > invented.
>
> Phantom tabs were added to allow you to reserve real estate for
> frequently used tabs while at the same time freeing up resources.
>
think of phantom tabs as closed mini tabs that have a reserved spot,
rather than merely a resource freeing technique.
application tabs. That proposal included removing the toolbar on those
tabs, much like the special application mode windows that Chromium
supports. I was not sure though if the disappearance of the toolbar
section when clicking on those tabs would cause too much user
confusion, which I am guessing is one of the concerns you have with
the idea too.
> > Either way, the url bar and
> > links on the page should treat external sites the same, shouldn't
> > they?
>
> > Has the code to have external links for app tabs open in a new tab
> > been implemented?
>
> These are still up in the air.
essential. I would be very surprised if clicking on a link in my Gmail
App tab caused the tab to navigate away rather than opening a new tab.
Once again, I would expect it to work like external links in
application mode windows. (The fact that that mode has external links
open in a new tab of a regular Chrome window makes it sound like quite
a bit of the necessary code has existed for a long time.)
> > Phantom tabs are distinguishable by the reduced opacity, although at
> > least with the default skin they can be rather difficult to
> > distinguish from regular mini tabs. Are there any plans to rectify
> > this? One possibility that sounds good to me, is to leave the favicon
> > fully opaque, but turn the opacity of the tab itself all the way down
> > to being completely transparent. the result is that phantom tabs look
> > like just icons floating in the tabbar. That makes them easy to
> > distinguish from other mini tabs. Furthermore, they would not actually
> > look like tabs, which would make why the window can close even with
> > them still there seem more intuitive. Thoughts?
>
> We've tried different things. I believe most folks are happy with the
> current look.
between a phantom tab and an inactive pinned tab as easily as I might
expect. If I only have one mini tab open, and one regular tab open and
selected, it is not particularly easy to tell if the mini tab is a
phantom tab or merely inactive, since I would have nothing to compare
it against. It might be clearer if I were using some theme other than
the default though.
Scott Violet
It's in the public repository (we try to develop everything in the
open). Search for nano in
http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/views/tabs/tab.cc?revision=48647&view=markup
. It's purely a view name though.
Yes.
> If so, the larger icon is stored as part of the extension?
The url Aaron just sent around documents how extensions specify other
icons, including the one used by the tabstrip.
-Scott
username at localhost
On Jun 9, 2:05 pm, Peter Kasting <pkast...@google.com> wrote:
> On Wed, Jun 9, 2010 at 10:24 AM, username at localhost <
>
> > The first mini tab to exist was the Pinned tab. When this tab was
> > first developed there was talk about it having all external links open
> > in a new tab, making them function much like the abstract concept of
> > an Application tab. As far as I can tell, that functionality was never
> > implemented, but the address bar had similar functionality added.
> > Specifically, in a pinned tab, one could change the URL to another
> > page on the same site, and that page would open in the pinned tab, but
> > type a URL for a different page, and that would be opened in a new
> > tab.
>
> Our current thinking is to reverse this, actually: navigations to a new host
> in a pinned tab would be kicked to another tab, while explicit typing would
> navigate the current tab. Seehttp://code.google.com/p/chromium/issues/detail?id=29281#c9;
> implementations welcome.
omnibar should should allow converting an app tab (regardless of
pinned status) to a regular tab.
> The logical behavior here would vary upon
>
> > whether the setting to restore tabs is set. If it is set, the tabs
> > should be restored in the state they were in when closed. If the
> > restore tabs setting is not set, then logically app tabs and app tabs
> > lite should be restored as phantom tabs, and a regular tab should be
> > opened and have focus (with the new tab page or homepage as
> > applicable).
>
> I disagree. I think it makes sense for pinned tabs to be restored in the
> state they were in regardless of the startup setting.
is to open a new page when I start the browser, that should still
happen, and should be the selected tab. Similarly, If I have it set
to show my homepage on startup, I should get a tab with my homepage.
username at localhost
There are pinned tabs. These display as mini tabs. They are remembered
between browsing sessions., and when closed they become phantom tabs.
Phantom tabs don't have an associated instance of the rendering
engine. They also don't prevent a browser window from closing. When
clicked they revert to being pinned tabs. If unpinned, phantom tabs
are closed. Phantom tabs are displayed behind all other tabs, and with
reduced opacity.
There are app tabs. These are special Mini tabs that are associated
with an extension. They display as nano tabs. App tabs can be pinned
like other tabs. There is no visual differentiation between pinned and
non-pinned app tabs at this time. At the moment it app tabs appear to
have the toolbar disabled by default, but it can be re-enabled via the
context menu. That menu option might not remain long-term.
Currently the handling of external links for both app tabs and regular
pinned tabs is still incomplete. Further it sounds like he exact
behavior has not yet fully been decided.
Although never explicitly stated in the current documentation, the
extensions that create apps can also do other extension things, like
add a browser action. I believe that is fully intended, and will
remain around.
The way App tabs will be launched in regular chromium (rather than
ChromiumOS) is still to be determined, but at the moment they are
listed on the new tab screen.
That sound about right?
Aaron Boodman
<username....@gmail.com> wrote:
> Although never explicitly stated in the current documentation, the
> extensions that create apps can also do other extension things, like
> add a browser action. I believe that is fully intended, and will
> remain around.
Undecided.
> The way App tabs will be launched in regular chromium (rather than
> ChromiumOS) is still to be determined, but at the moment they are
> listed on the new tab screen.
>
> That sound about right?
Other than the above, everything related to extensions is correct.
- a
Peter Kasting
On Jun 9, 2:05 pm, Peter Kasting <pkast...@google.com> wrote:> Our current thinking is to reverse this, actually: navigations to a new host> navigate the current tab. Seehttp://code.google.com/p/chromium/issues/detail?id=29281#c9;
> in a pinned tab would be kicked to another tab, while explicit typing would
> implementations welcome.
Sounds sane for pinned regular tabs, but I'm not sure if typing in the
omnibar should should allow converting an app tab (regardless of
pinned status) to a regular tab.
if my settingis to open a new page when I start the browser, that should still
happen, and should be the selected tab. Similarly, If I have it set
to show my homepage on startup, I should get a tab with my homepage.
PK
Mike Belshe
Alayari, John
Does anyone know if we can run each V8 Benchmark test (e.g. splay) individually from the browser?
Thanks in advance.
-John
Mike Belshe
--