There are heuristics we can come up with that are fairly safe. They might be too conservative to be useful though. For example, it should almost always be safe to kill a page that:-has no unload/beforeunload listeners registered -has had no user-interaction that caused JS to execute -has had no user-interaction that changed form field values
If we're really worried, we could get arbitrarily strict, e.g. never kill a page with any form fields. But the stricter we get, the less useful this becomes. My definition of safe here is that there generally won't be enough page state lost that the user will notice or care if we kill it. That said, I don't quite get what happens when the user finally switches back to that tab, do we refetch it from the network? What if I was intentionally loading tabs to read because I knew I was going to be disconnected from the network soon (e.g. getting on an airplane)? What if I'm on a bad connection and pages aren't loading well? etc. Ojan On Wed, Jul 22, 2009 at 10:27 AM, David Levin <[email protected]> wrote: > There is one internal site that I go to enter some feedback. (It has auto > save now but didn't at one point.) > Recently I don't go there very often. It is entirely possible (and > frequently happens) that I get interrupted while entering feedback and have > to look up other information (during which I look up information from lots > of sources). Then I go back and expect my feedback to still be there. I > would be highly annoyed at any browser that tossed my feedback (which takes > me a while to write). > > An external example of this is the review tool for WebKit (which doesn't > have auto-save and doesn't have a manual draft save mode even). > > dave > > > On Wed, Jul 22, 2009 at 9:54 AM, Linus Upson <[email protected]> wrote: > >> With a good heuristic, I think it will be very unlikely that we'll kill a >> renderer that has useful state. What are the chances that a tab on a site >> that I don't go to often, and that I opened 30 tabs ago has js/dom state >> that is critical for me? Mobile browsers already euthanize unused >> tabs aggressively. Since so few users have 20+ tabs open at once perhaps we >> can just reset their expectations for what happens if they accumulate a >> large number of tabs. Perhaps the heuristic could be tied to the mythical >> great overflow UI. For all of these heavy users I suspect they would prefer >> chrome to remain zippy fast with large tab sets rather than paging a >> renderer that 99.9% of the time doesn't have any interesting state. >> Linus >> >> >> On Tue, Jul 21, 2009 at 2:03 PM, Scott Hess <[email protected]> wrote: >> >>> >>> I don't think it's reasonable to require the user to specify which >>> tabs to suspend, except, perhaps, if we develop a metric for >>> power-hungry tabs and expose that. >>> >>> I think there is some potential for UI geared towards particular >>> use-cases which could be overloaded to also allow more aggressive >>> suspend. For instance, WRT my earlier posting, I would expect my >>> pinned tabs to be given stronger priority, and my on-deck-to-read tabs >>> to be treated more like preloaded/rendered bookmarks. There could be >>> other UI advantages in there, like the on-deck tabs for a particular >>> project could group under a single tab with other UI widgets to select >>> which document within the group. >>> >>> -scott >>> >>> >>> On Tue, Jul 21, 2009 at 1:50 PM, Ryosuke Niwa<[email protected]> wrote: >>> > Is it possible to provide an intuitive UI that allows users to choose >>> which >>> > tabs to be suspended? >>> > For example, just like users can click buttons on taskbar to pop up a >>> > particular window, we could provide a small window that pop-in tabs / >>> > windows. And then we can suspend all windows / tab that >>> are popped into. >>> > Ryosuke >>> > >>> > On Tue, Jul 21, 2009 at 9:32 AM, Erik Kay <[email protected]> >>> wrote: >>> >> >>> >> You may be on to something, but I think it's more complex than this. >>> For >>> >> example bookmark systems don't work because people use them for a >>> number of >>> >> conflicting purposes (my list of things to read every day, a simple >>> history >>> >> system, a 'to read' list, a collection of links for research), which >>> have >>> >> different UI requirements. I think the same thing has happened with >>> tabs >>> >> (and there's a surprising amount of overlap). Here are the use cases >>> I know >>> >> I wind up using: >>> >> - a few long running apps that need to keep running, potentially >>> notifying >>> >> me of new events (calendar, mail, chat, buildbot, etc.) >>> >> - a few pages that I'm currently actively using (a screenshot from a >>> bug >>> >> I'm looking at, some reference documentation, a writely page I'm >>> editing >>> >> between compiles, etc.) >>> >> - a "to read" list of pages that I started reading but didn't finish >>> yet >>> >> (sometimes this is a collection of related pages when researching >>> something) >>> >> - I'm sure there are others. >>> >> 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? (yes, some of this is bad app >>> design, >>> >> but there are many like this) Which ones do I expect to keep running >>> all of >>> >> the time because of notifications? What about that flash game that I >>> left >>> >> running in the background? >>> >> Maybe we could come up with some heuristics that could detect some of >>> this >>> >> automatically, but I worry that there will be so many exceptions that >>> it >>> >> won't work. That means we'd need to come up with a better UI to >>> express >>> >> these concepts where the user chose to treat tabs differently in some >>> >> explicit way. There are a number of extensions that try to do this >>> for some >>> >> specific use cases (to read lists, pinned tabs, etc.). I'm not sure >>> that >>> >> these are better than bandaids though. >>> >> Erik >>> >> >>> >> On Tue, Jul 21, 2009 at 8:28 AM, Dean McNamee <[email protected]> >>> wrote: >>> >>> >>> >>> I feel like people are using tabs as a replacement for a good history >>> >>> system. At least in all current browser implementations, tabs are >>> >>> "running". Even if we can make the UI scale to 1000 tabs, the 500 >>> >>> flash instances that are likely running aren't really going to >>> >>> perform. The making tab performance scale is a separate technical >>> >>> issue that will hopefully also improve. >>> >>> >>> >>> Looking at a lot of these design videos, they looked more like good >>> >>> ideas to me for history navigation than tab navigation. If history >>> >>> was good, I think people wouldn't be so worried about "losing >>> >>> something" by closing a tab. Having had bad history systems for so >>> >>> many years, people are now trained to keep tabs open if they ever >>> >>> might want to look at that page again in the future :\ >>> >>> >>> >>> On Sat, Jul 18, 2009 at 1:16 AM, Peter Kasting<[email protected]> >>> >>> wrote: >>> >>> > http://design-challenge.mozilla.com/summer09/ >>> >>> > The results of the "Reinventing Tabs in the Browser" challenge have >>> >>> > been >>> >>> > announced. >>> >>> > "Collapsible Tab Groups" includes among others some things I've >>> >>> > proposed, >>> >>> > including grouping and collapsing groups. >>> >>> > "Favitabs" reminds me of some old brainstorming ideas from pamg >>> about >>> >>> > converting certain tabs into favicon buttons. >>> >>> > Folks considering the future of tabs (e.g. Ben, Glen, Scott) might >>> do >>> >>> > well >>> >>> > to take a look at some of these. >>> >>> > PK >>> >>> > > >>> >>> > >>> >>> >>> >>> >>> >> >>> >> >>> >> >>> > >>> > >>> > > >>> > >>> >>> >>> >> >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ Chromium Developers mailing list: [email protected] View archives, change email options, or unsubscribe: http://groups.google.com/group/chromium-dev -~----------~----~----~----~------~----~------~--~---
