cros: Preload and reuse the lock screen across lock sessions

cros: Preload and reuse the lock screen across lock sessions

This is currently behind a feature flag and not enabled by default.

- The lock screen webview will be saved and reused across lock sessions.
- The lock screen webview will be preloaded after the user has not generated any input events for 8 seconds.

See https://codereview.chromium.org/2512473004/ for additional context.

BUG=669638
Committed: https://crrev.com/314a23a11c9ed8c9a3b0a51816a20c84f4fd822d
Cr-Commit-Position: refs/heads/master@{#438698}

[jdufault, 2016-12-05 20:54:19]

The CQ bit was checked by jdufault@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-05 20:55:12]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[jdufault, 2016-12-05 22:01:43]

The CQ bit was checked by jdufault@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-05 22:02:31]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[jdufault, 2016-12-05 22:41:09]

Description was changed from

==========
IGNORE: webview-preload

BUG=669638
==========

to

==========
cros: Preload and reuse the lock screen across lock sessions

- The lock screen webview will be saved and reused across lock sessions.
- The lock screen webview will be preloaded after the user has not generated any
input events for 8 seconds.

BUG=669638
==========

[jdufault, 2016-12-05 22:47:59]

Description was changed from

==========
cros: Preload and reuse the lock screen across lock sessions

- The lock screen webview will be saved and reused across lock sessions.
- The lock screen webview will be preloaded after the user has not generated any
input events for 8 seconds.

BUG=669638
==========

to

==========
cros: Preload and reuse the lock screen across lock sessions

This is currently behind a feature flag and not enabled by default.

- The lock screen webview will be saved and reused across lock sessions.
- The lock screen webview will be preloaded after the user has not generated any
input events for 8 seconds.

BUG=669638
==========

[commit-bot: I haz the power, 2016-12-05 23:03:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-05 23:03:03]

Dry run: This issue passed the CQ dry run.

[jdufault, 2016-12-06 21:50:52]

The CQ bit was checked by jdufault@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-06 21:51:21]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[jdufault, 2016-12-06 23:16:13]

Patchset #1 (id:1) has been deleted

[jdufault, 2016-12-06 23:16:21]

Patchset #1 (id:20001) has been deleted

[commit-bot: I haz the power, 2016-12-07 00:22:11]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-07 00:22:12]

Dry run: This issue passed the CQ dry run.

[jdufault, 2016-12-07 18:09:37]

Description was changed from

==========
cros: Preload and reuse the lock screen across lock sessions

This is currently behind a feature flag and not enabled by default.

- The lock screen webview will be saved and reused across lock sessions.
- The lock screen webview will be preloaded after the user has not generated any
input events for 8 seconds.

BUG=669638
==========

to

==========
cros: Preload and reuse the lock screen across lock sessions

This is currently behind a feature flag and not enabled by default.

- The lock screen webview will be saved and reused across lock sessions.
- The lock screen webview will be preloaded after the user has not generated any
input events for 8 seconds.

See https://codereview.chromium.org/2512473004/ for additional context.

BUG=669638
==========

[jdufault, 2016-12-07 18:10:55]

jdufault@chromium.org changed reviewers:
+ achuith@chromium.org, alemate@chromium.org

[jdufault, 2016-12-07 18:12:11]

achuith@, alemate@, PTAL. Thanks.

[jdufault, 2016-12-09 19:12:11]

jdufault@chromium.org changed reviewers:
+ xiyuan@chromium.org

[jdufault, 2016-12-09 19:21:06]

xiyuan@ PTAL since achuith@ is OOO.

[xiyuan, 2016-12-09 22:59:55]

https://codereview.chromium.org/2553863002/diff/40001/chrome/browser/chromeos...
File chrome/browser/chromeos/login/lock/webui_screen_locker.cc (right):

https://codereview.chromium.org/2553863002/diff/40001/chrome/browser/chromeos...
chrome/browser/chromeos/login/lock/webui_screen_locker.cc:87:
profile->GetPrefs()->GetBoolean(prefs::kEnableAutoScreenLock);
Why do we need to associate with kEnableAutoScreenLock ?

https://codereview.chromium.org/2553863002/diff/40001/chrome/browser/chromeos...
File chrome/browser/chromeos/login/session/chrome_session_manager.cc (right):

https://codereview.chromium.org/2553863002/diff/40001/chrome/browser/chromeos...
chrome/browser/chromeos/login/session/chrome_session_manager.cc:50: const int
IDLE_SECONDS_BEFORE_PRELOADING_LOCK_SCREEN = 8;
const -> constexpr

IDLE_SECONDS_BEFORE_PRELOADING_LOCK_SCREEN ->
kIdelSecondsBeforePreloadingLockScreen

[jdufault, 2016-12-10 01:06:11]

The CQ bit was checked by jdufault@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-10 01:06:51]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[Alexander Alekseev, 2016-12-10 01:33:14]

lgtm

[commit-bot: I haz the power, 2016-12-10 03:54:10]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-10 03:54:11]

Dry run: This issue passed the CQ dry run.

[jdufault, 2016-12-12 20:08:27]

https://codereview.chromium.org/2553863002/diff/40001/chrome/browser/chromeos...
File chrome/browser/chromeos/login/lock/webui_screen_locker.cc (right):

https://codereview.chromium.org/2553863002/diff/40001/chrome/browser/chromeos...
chrome/browser/chromeos/login/lock/webui_screen_locker.cc:87:
profile->GetPrefs()->GetBoolean(prefs::kEnableAutoScreenLock);
On 2016/12/09 22:59:55, xiyuan wrote:
> Why do we need to associate with kEnableAutoScreenLock ?

It is the primary heuristic to try and figure out if the user actively locks
their screen. If set to false then no lock screen will appear after a device
goes to sleep.

Maybe an alternative would be an unsycned pref recording the last time the user
manually locked their screen. If it has been longer than a week, don't preload?

https://codereview.chromium.org/2553863002/diff/40001/chrome/browser/chromeos...
File chrome/browser/chromeos/login/session/chrome_session_manager.cc (right):

https://codereview.chromium.org/2553863002/diff/40001/chrome/browser/chromeos...
chrome/browser/chromeos/login/session/chrome_session_manager.cc:50: const int
IDLE_SECONDS_BEFORE_PRELOADING_LOCK_SCREEN = 8;
On 2016/12/09 22:59:55, xiyuan wrote:
> const -> constexpr
> 
> IDLE_SECONDS_BEFORE_PRELOADING_LOCK_SCREEN ->
> kIdelSecondsBeforePreloadingLockScreen

Done.

[xiyuan, 2016-12-12 20:33:19]

https://codereview.chromium.org/2553863002/diff/40001/chrome/browser/chromeos...
File chrome/browser/chromeos/login/lock/webui_screen_locker.cc (right):

https://codereview.chromium.org/2553863002/diff/40001/chrome/browser/chromeos...
chrome/browser/chromeos/login/lock/webui_screen_locker.cc:87:
profile->GetPrefs()->GetBoolean(prefs::kEnableAutoScreenLock);
On 2016/12/12 20:08:27, jdufault wrote:
> On 2016/12/09 22:59:55, xiyuan wrote:
> > Why do we need to associate with kEnableAutoScreenLock ?
> 
> It is the primary heuristic to try and figure out if the user actively locks
> their screen. If set to false then no lock screen will appear after a device
> goes to sleep.
> 
> Maybe an alternative would be an unsycned pref recording the last time the
user
> manually locked their screen. If it has been longer than a week, don't
preload?

How about using the following:

https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/users/chro...

[xiyuan, 2016-12-12 20:43:36]

https://codereview.chromium.org/2553863002/diff/40001/chrome/browser/chromeos...
File chrome/browser/chromeos/login/lock/webui_screen_locker.cc (right):

https://codereview.chromium.org/2553863002/diff/40001/chrome/browser/chromeos...
chrome/browser/chromeos/login/lock/webui_screen_locker.cc:87:
profile->GetPrefs()->GetBoolean(prefs::kEnableAutoScreenLock);
On 2016/12/12 20:33:19, xiyuan wrote:
> On 2016/12/12 20:08:27, jdufault wrote:
> > On 2016/12/09 22:59:55, xiyuan wrote:
> > > Why do we need to associate with kEnableAutoScreenLock ?
> > 
> > It is the primary heuristic to try and figure out if the user actively locks
> > their screen. If set to false then no lock screen will appear after a device
> > goes to sleep.
> > 
> > Maybe an alternative would be an unsycned pref recording the last time the
> user
> > manually locked their screen. If it has been longer than a week, don't
> preload?
> 
> How about using the following:
> 
>
https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/users/chro...

On a second thought, the problem we are trying to solve is the timeout when lock
on suspending. So what you have makes sense now. :) Let's comment that clearly.

[jdufault, 2016-12-12 21:06:02]

The CQ bit was checked by jdufault@chromium.org to run a CQ dry run

[jdufault, 2016-12-12 21:06:27]

https://codereview.chromium.org/2553863002/diff/40001/chrome/browser/chromeos...
File chrome/browser/chromeos/login/lock/webui_screen_locker.cc (right):

https://codereview.chromium.org/2553863002/diff/40001/chrome/browser/chromeos...
chrome/browser/chromeos/login/lock/webui_screen_locker.cc:87:
profile->GetPrefs()->GetBoolean(prefs::kEnableAutoScreenLock);
On 2016/12/12 20:43:36, xiyuan wrote:
> On 2016/12/12 20:33:19, xiyuan wrote:
> > On 2016/12/12 20:08:27, jdufault wrote:
> > > On 2016/12/09 22:59:55, xiyuan wrote:
> > > > Why do we need to associate with kEnableAutoScreenLock ?
> > > 
> > > It is the primary heuristic to try and figure out if the user actively
locks
> > > their screen. If set to false then no lock screen will appear after a
device
> > > goes to sleep.
> > > 
> > > Maybe an alternative would be an unsycned pref recording the last time the
> > user
> > > manually locked their screen. If it has been longer than a week, don't
> > preload?
> > 
> > How about using the following:
> > 
> >
>
https://cs.chromium.org/chromium/src/chrome/browser/chromeos/login/users/chro...
> 
> On a second thought, the problem we are trying to solve is the timeout when
lock
> on suspending. So what you have makes sense now. :) Let's comment that
clearly.

I've added a comment.

[commit-bot: I haz the power, 2016-12-12 21:07:09]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[xiyuan, 2016-12-12 21:07:38]

lgtm

[commit-bot: I haz the power, 2016-12-13 01:52:08]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-13 01:52:09]

Dry run: Try jobs failed on following builders:
  linux_chromium_asan_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[jdufault, 2016-12-14 22:24:14]

The CQ bit was checked by jdufault@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2016-12-14 22:24:38]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-14 23:55:03]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2016-12-14 23:55:05]

Dry run: This issue passed the CQ dry run.

[jdufault, 2016-12-15 00:19:31]

The CQ bit was checked by jdufault@chromium.org

[jdufault, 2016-12-15 00:19:31]

The patchset sent to the CQ was uploaded after l-g-t-m from
alemate@chromium.org, xiyuan@chromium.org
Link to the patchset: https://codereview.chromium.org/2553863002/#ps120001
(title: "Rebase")

[commit-bot: I haz the power, 2016-12-15 00:20:24]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2016-12-15 01:17:45]

CQ is committing da patch.

Bot data: {"patchset_id": 120001, "attempt_start_ts": 1481761171320680,
"parent_rev": "b462479efedc700e92f9bc70fe89e4d76f0afcac", "commit_rev":
"85582c9e0da7fa849c9341407f6fdeaea4edf889"}

[commit-bot: I haz the power, 2016-12-15 01:18:40]

Description was changed from

==========
cros: Preload and reuse the lock screen across lock sessions

This is currently behind a feature flag and not enabled by default.

- The lock screen webview will be saved and reused across lock sessions.
- The lock screen webview will be preloaded after the user has not generated any
input events for 8 seconds.

See https://codereview.chromium.org/2512473004/ for additional context.

BUG=669638
==========

to

==========
cros: Preload and reuse the lock screen across lock sessions

This is currently behind a feature flag and not enabled by default.

- The lock screen webview will be saved and reused across lock sessions.
- The lock screen webview will be preloaded after the user has not generated any
input events for 8 seconds.

See https://codereview.chromium.org/2512473004/ for additional context.

BUG=669638

Review-Url: https://codereview.chromium.org/2553863002
==========

[commit-bot: I haz the power, 2016-12-15 01:18:42]

Committed patchset #5 (id:120001)

[commit-bot: I haz the power, 2016-12-15 01:21:08]

Description was changed from

==========
cros: Preload and reuse the lock screen across lock sessions

This is currently behind a feature flag and not enabled by default.

- The lock screen webview will be saved and reused across lock sessions.
- The lock screen webview will be preloaded after the user has not generated any
input events for 8 seconds.

See https://codereview.chromium.org/2512473004/ for additional context.

BUG=669638

Review-Url: https://codereview.chromium.org/2553863002
==========

to

==========
cros: Preload and reuse the lock screen across lock sessions

This is currently behind a feature flag and not enabled by default.

- The lock screen webview will be saved and reused across lock sessions.
- The lock screen webview will be preloaded after the user has not generated any
input events for 8 seconds.

See https://codereview.chromium.org/2512473004/ for additional context.

BUG=669638

Committed: https://crrev.com/314a23a11c9ed8c9a3b0a51816a20c84f4fd822d
Cr-Commit-Position: refs/heads/master@{#438698}
==========

[commit-bot: I haz the power, 2016-12-15 01:21:09]

Patchset 5 (id:??) landed as
https://crrev.com/314a23a11c9ed8c9a3b0a51816a20c84f4fd822d
Cr-Commit-Position: refs/heads/master@{#438698}