Extension disable() called on session mode change, but only for the first time

[stephen_byerley]

I’m not sure if this is a recent regression. I noticed it for the first time during debugging this weekend.

The first screen lock after login will flap disable() and then immediately enable() for an extension. All other screen locks afterwards will not repeat this behavior.

The extension I’m testing on is configured to work with the unlock-dialog session mode.

[fmuellner (Florian Müllner)]

@stephen_byerley

The first screen lock after login will flap disable() and then immediately enable() for an extension. All other screen locks afterwards will not repeat this behavior.

Unless there’s a bug (which is of course possible), this is what I think is happening:

1. on session mode change, extensions that shouldn’t be enabled are disabled
2. when an extension is disabled, newer extensions are “rebased”:
   • take extensions A-B-C-D
   • to disable extensions B, we disable (in that order) D-C-B
   • complete by (re)enabling C-D
3. after unlock, extensions that were disabled on the lock screen are enabled again
4. extensions that are allowed on the lock screen are now at the “bottom” of the stack, so on the next session mode change, rebasing isn’t necessary again

(step 2 is done to handle the case where several extensions save/modify/restore the same function)