https://crrev.com/c/806044 is a partial fix, but I am apparently not understanding the notions of actions and back stack enough, because that CL reduces the number of displayed lock screens to 2 instead of 1. While better than nothing, definitely not ideal.

Cc-ing twellington@ and melandory@ in case they have any comments or hints.

Does the authentication screen keeping popping up at step #3 with your current CL? If so, do you know which block of code is requesting the re-authentication screen to show?

It does pop up the second time (but no more than that).

When I was inspecting that in debugger, I checked how many times the lock-screen intent is started [1] and it only happened once, not twice.

Also the onActivityResult from the same class (PasswordReauthenticationFragment) seemed to be triggered just once. On the other hand, PasswordReauthenticationFragment#onCreate was triggered twice (and onSaveInstanceState once). In the second invocation it correctly skipped lockDevice(), but at the same time, the screen lock popped up on the device.


[1] https://chromium.googlesource.com/chromium/src/+/8973c4cd5554fa4833cdd88f24be96361f4caf61/chrome/android/java/src/org/chromium/chrome/browser/preferences/password/PasswordReauthenticationFragment.java#72

PasswordReauthenticationFragment's sole responsibility is showing the lock screen. I think if its #onCreate() method gets called with a saved bundle, that indicates the user is returning to the activity after it has been paused/destroyed & recreated. What happens if you skip the lockDevice() call in onCreate() if the saved bundle isn't null?

Thanks for your answer.

What #4 suggests is actually what https://crrev.com/c/806044 already does -- that's where I get the two lock screens instead of an infinite amount of them.

For the record, I also tried to modify the code so that there is no custom #onSaveInstanceState and no custom key added, and it still works the same: 2 lock screens on my Nexus 7 (Android M userdebug). I will upload the simplified patch to that CL.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/3344d95a6f3668cb591678bf803911c4bdc9000d

commit 3344d95a6f3668cb591678bf803911c4bdc9000d
Author: Vaclav Brozek <vabr@chromium.org>
Date: Thu Dec 07 10:50:19 2017

[Android settings] Break the infinite re-spawning of reauth screen

This change adds a safeguard in PasswordReauthenticationFragment against
repeated showing of the screen lock.

If PasswordReauthenticationFragment gets killed during displaying the screen
lock, this CL ensures that it won't attempt to display it again on re-creation.

Bug: 791652
Change-Id: I7cc593906017bd059c6a4f3bd2b88d9b68488398
Reviewed-on: https://chromium-review.googlesource.com/806044
Commit-Queue: Vaclav Brozek <vabr@chromium.org>
Reviewed-by: Theresa <twellington@chromium.org>
Cr-Commit-Position: refs/heads/master@{#522395}
[modify] https://crrev.com/3344d95a6f3668cb591678bf803911c4bdc9000d/chrome/android/java/src/org/chromium/chrome/browser/preferences/password/PasswordReauthenticationFragment.java

r522395 should get rid of the infinite loop, but it would still be good to know why there are two lock screens in a row instead of just one.

As I'm about to be unavailable for a few weeks, I am marking this as Available again, and might return to it in 2018.

Interesting, I just tested this behaviour on a Nexus 4 with L and the infinite loop is still present there (while the same build is still restricted to the single repetition of the reauth screen for Nexus 7 with M).

So far, Android Studio's debugger shows me that (on Nexus 4 with L), the isFirstTime value in PasswordReauthenticationFragment's onCreate is always true.

I need to investigate further.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/beb0b3356ff35da4f2a3c92ecfdb6c24f587d36c

commit beb0b3356ff35da4f2a3c92ecfdb6c24f587d36c
Author: Vaclav Brozek <vabr@chromium.org>
Date: Fri Jan 19 16:03:17 2018

[Android L settings] Break the infinite re-spawning of reauth screen

This CL extends https://crrev.com/522395 to Android L.

The problem:
Under memory pressure (emulated in Developer options by "Don't keep
activities"), PasswordReauthenticationFragment gets killed after it
spawns the OS-level reauthentication dialogue. On restoration,
PasswordReauthenticationFragment forgets that it already spawned the
dialogue, and does it again, in an infinite loop.

The solution from https://crrev.com/522395:
Check the existence of the saved state in onCreate, and only re-spawn
the dialogue if it is absent (indicating the first run).

The Android L problem:
It appears that, unlike under Android M, under L the saved state is
null even in re-creations, as long as nothing has been saved into it
in onSaveInstanceState.

The Android L solution, added in this CL:
Save a dummy value in the saved state in onSaveInstanceState.

Note: For some reason, the general solution still does not work
perfectly and only reduces the infinite series of auth dialogues to 2
(instead of to 1). This continues to be happening after this CL and
will be investigated separately.

Bug: 791652
Change-Id: I336af2f996e9cae5cae6d9370e2e81db91eb84a4
Reviewed-on: https://chromium-review.googlesource.com/874694
Reviewed-by: Theresa <twellington@chromium.org>
Commit-Queue: Vaclav Brozek <vabr@chromium.org>
Cr-Commit-Position: refs/heads/master@{#530524}
[modify] https://crrev.com/beb0b3356ff35da4f2a3c92ecfdb6c24f587d36c/chrome/android/java/src/org/chromium/chrome/browser/preferences/password/PasswordReauthenticationFragment.java

I'm sadly very unlikely to touch this until I leave the team by the end of the month, so pushing back into the available bugs.