- Additional state should be maintained if possible: forms, scroll position, etc.
- Quit and Keep Windows, new menu item modifier also exists

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

Moving out of M12.

Moving !type=meta|regression and !releaseblocker to next mstone

(No comment was entered for this change.)

Now that the Lion’s out of the bag, these are safe to open up to the world.

It would be great if we could restore form data, scroll position, etc. I tested Safari on Lion Developer Preview, and it just seems to do the equivalent of Chrome's session restore -- just reloads the tabs that were open. No other state is restored.

dubroy, we do restore some of these. We don't restore the complete state of the page though (state meaning script state, dom...), which means some state manipulated by way of script may not get restored. Also, see 51313 for scroll position.

A few observations and thoughts on this one:

(1) We should be sensitive to the global system preference:

	System Preferences > General > Restore windows when quitting and reopening the app

The subtly here	is that this global checkbox effectively duplicates two states of our "On Startup" radio group:
	o Open the home page
	o Reopen the pages that were last open

The Chromium preference that controls this is kRestoreOnStartup.  It's values can be (SessionStartupPref) "DEFAULT", "LAST", and "URLS".  But really, "DEFAULT" means "don't restore".  There's also a fourth, implicit, "NULL" state where the user has not set anything themselves.

-- Solution A --
When the user is in the "NULL" state, meaning they have not explicitly set a preference for this, we would take the System setting as the default behavior.

If the user uses the Chrome preferences UI to explicitly change the setting then we respect the local override.  This gives the advantage of respecting system settings but allowing Chromium users to override it locally.  The problem with this is that there's no way to change back to the "NULL" state once a choice has been made.  That may be ok.

-- Solution B --
An alternate approach would be to get rid of the "On Startup" radio group and just have a single checkbox for "Open the following pages:".  The other two radio choices (Open home / Open last) would be removed in favor of the System settings.

This seems like the most "Lion-y" way.  But there are a lot of Safari users complaining about this global setting and they're having to resort to command-line (defaults) hacks to reset this pref locally.

Overall, I'd propose Solution A.


(2) Non-browser windows stickiness.  Chromium's "Task Manager" window is not sticky but should be.  This is true for Snow Leopard as well.


(3) Depending on the state of the System setting the application's Quit menu, when holding the option key, toggles between "Quit and Discard Windows" and "Quit and Keep Windows".  This is Lion messing with Chromium.  And we don't actually respect the choice made.

This needs fixing.  The Option-Quit menu should:
  a) read "Quit and Keep Windows" when "Open the home page" is selected,
  b) read "Quit and Discard Windows" when "Reopen the pages..." is selected,
  c) read "Quit" when "Open the following pages" is selected.

And, of course, they should all do the right thing on a quit/relaunch cycle.


(4) Interaction with Fullscreen mode.
If the user quits while in Fullscreen mode and the System "Restore windows..." is checked, then upon relaunch we should enter back into Fullscreen mode automatically.


As noted by others, there is more state we could preserve, like scroll position, form state, item focus, etc. but IMO (1)...(4) represents the core functionality we need currently.

Punting out non-critical bugs.  Please move back to 14 if you believe this was done in error.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=94605

------------------------------------------------------------------------
r94605 | dhollowa@chromium.org | Thu Jul 28 17:54:34 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/webui/options/browser_options_handler.h?r1=94605&r2=94604&pathrev=94605
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/resources/options/browser_options.js?r1=94605&r2=94604&pathrev=94605
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/window_restore_utils.mm?r1=94605&r2=94604&pathrev=94605
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/resources/options/browser_options.html?r1=94605&r2=94604&pathrev=94605
 A http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/window_restore_utils.h?r1=94605&r2=94604&pathrev=94605
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/chrome_browser.gypi?r1=94605&r2=94604&pathrev=94605
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/webui/options/browser_options_handler.cc?r1=94605&r2=94604&pathrev=94605
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/prefs/session_startup_pref.cc?r1=94605&r2=94604&pathrev=94605
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/gesture_utils.mm?r1=94605&r2=94604&pathrev=94605

Turn on session restore by default for mac on Lion

When the user has not explicitly set a preference in Chrome for session restore, the default behavior under Lion becomes sensitive to the System preference for window restore.

BUG=75814
TEST=SessionStartupPrefTest.*, and manual testing of WebUI: clean prefs, Launch Chrome, toggle "System Preferences > General > Restore windows..." and observe effect on Chrome preferences "Basics > On Startup".

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

(No comment was entered for this change.)

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=95120

------------------------------------------------------------------------
r95120 | dhollowa@chromium.org | Tue Aug 02 11:48:40 PDT 2011

Changed paths:
 M http://src.chromium.org/viewvc/chrome/trunk/src/chrome/browser/ui/cocoa/window_restore_utils.mm?r1=95120&r2=95119&pathrev=95120

Session restore by default should account for uninitialized state

Corrects logic for when Lion does not explicitly set a default for session restore.  The implicit default is that session restore is enabled.

BUG=75814
TEST=Manual testing.


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

From what I've seen of Apple's Lion apps, the window "pop-in" animation (eg. http://static.arstechnica.net/2011/07/04/lion/lion-new-windows.mp4) should only occur on "new" windows or application states. "Resumed" windows are not meant to have the window animation, they just appear immediately. From what I've tested in 15.0.842.0 canary (wiped prefs and appsupport), Chrome seems to be doing the opposite.

Also I feel like more than a few people, like me, would want to manually enable the standard Resume over Chrome's session restore without resetting the preferences. Like you mentioned, it seems to be hard or impossible to enable this if you've fiddled around with the preferences, unless you clear the app pref files. Apologies if I've got any of that wrong.

Bug in Canary 15.0.847.0:  In Lion, holding down the alt/option key while quitting apps that support resume will quit and discard all the open windows.  Canary isn't obeying this and is quitting, then restoring all the open windows on next launch.

Holding down the alt key while quitting should quit Chrome, and open up with a fresh new session on next launch.  Perhaps with the Home Page settings?

Yes, this is known and mentioned in point (3) above.

(No comment was entered for this change.)

The page content should be saved and not reloaded when re-opening Chrome. 

When one has dozens of windows with dozens of tabs each, it takes forever to reload everything. 

If I want updated content I can reload it manually...but it does't auto-reload while using the browser, and it shouldn't auto-reload just because I closed and reopened the app, it should just come back exactly as before and as fast as possible, ideally just put everything in memory as it was before and save memory to disk in the end, just like the OS hibernate function...simple and effective.

Another useful feature that is now done in Safari is auto-unloading of memory of tabs that are not used for some time...I don't want to close them but I don't need them to be kept in memory and running all the time, and when "reactivated" in this case they shouldn't have to reload content from the web either, just be fetched from disk to memory again.

This would be the perfect scenario for anyone that likes to have many open windows/tabs, and I think it is possible and should have been done already if you want to stay ahead of the competition.

There are many other bugs and features of session restore that should be addressed at the same time as Lion users will be starting to expect from good apps.

For example, it should be space-sensitive. It is very annoying to organize Chrome windows in different desktops, just to loose everything on a session restore that doesn't restore the window position.

Spaces restore is  bug 94606 .

Minimization state is  bug 43274 .

Quit menu is bug 94609.  (Currently blocked on Apple).

(No comment was entered for this change.)

Fullscreen restore is  bug 94611 .

Task Manager window resume is bug 94612.

Essential functionality for M15 is in.  The remaining work is tracked as dependent bugs.  Keeping this as a meta-ish bug until remaining work is complete.

(No comment was entered for this change.)

Moving bugs marked as Available but not blockers from M17 to M18.  Please move back if you think this is a blocker, and add the ReleaseBlock-Stable label.  If you're able.

PLEASE CONCENTRATE ON FIXING  BUG 94606 .  It's incredible that you would consider restoring the "full screen" state but not put the windows in the right workspaces! Unbearable. Stop pandering to n00b users who couldn't care less whether their two open windows are preserved or not with the Quit Menu Modifier and start making Chromium ROBUST FOR POWER USERS WHO DEPEND ON IT DAILY.  It still leaks memory like a dawg and when you have 20+GB of swap being used with 100+ open windows across 8 workspaces soon or later it's going to cause a freeze or crash and necessitate a restart -- so please FIX RESTORING THE WINDOWS TO THE RIGHT WORKSPACE when that restart happens. Nothing else here matters--screw the conflicted settings, just do the right thing! Solve the hard problem, not the UI button labels!

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

(No comment was entered for this change.)

M20 is about to sail in couple of days. If this should be part of M20, add it back.