On Tue, Jul 21, 2009 at 9:52 AM, Amanda Walker <ama...@chromium.org> wrote:
> On Tue, Jul 21, 2009 at 12:32 PM, Erik Kay<erik...@chromium.org> wrote:
> > In my use case, 80% of my tabs could easily be killed / suspended (or
> even
> > hidden altogether) without any downside to me. The problem is that there
> > isn't a way to automatically figure out which ones are which. Which ones
> > have pending state that might be lost?
>
> Well, to a first approximation, ones which have had user interaction
> besides scrolling since they were opened? (typing, navigating a link,
> etc.)
>
I frequently avoid interacting with articles from popular news sites for
thirty seconds or so (as they sit in the background) to let their stupid
interstitial ad timeouts fire.
Scott Hess' comment that some tabs could be changed into static documents is
accurate from a UX perspective, but as this thread has already mentioned
it's hard to decide which tabs those are. For example, today we load tabs
opened from gmail in the same renderer process as gmail because we don't
realize that those two pages are never going to script each other. If we
don't know page A and page B won't script each other, how can we freeze A or
B? To put it even more simply, if given a tab A, how do we know it won't
run script at some point in the future?
My own claim is that multiselection of tabs is implementable and useful, and
we should start by implementing that (which in fact Ben is currently doing,
I think), and then see if it helps any of our organization issues. After
that, perhaps some concept of tab pinning would be useful. The idea here is
to add things we know we can do in hopes that better usage patterns emerge,
instead of trying to envision the ideal design from nothing :)
PK
--~--~---------~--~----~------------~-------~--~----~
Chromium Developers mailing list: chromium-dev@googlegroups.com
View archives, change email options, or unsubscribe:
http://groups.google.com/group/chromium-dev
-~----------~----~----~----~------~----~------~--~---
