Without looking at the code I think this is because the window list is implemented as an extension and extensions are disabled on the lock screen and then re-enabled.

Perhaps we should just whitelist the classic mode extensions?

I think if it just created the list in window-creation-time order rather than last-used-timestamp order then that would work as well. Though I'm not sure anything currently keeps track of that.

Another possibility would be to just allow each extension to provide a bit of data to be saved when the screensaver goes on, which would be passed back to it when it's re-enabled. (Though then it would have to check if windows had been added or removed while it was disabled, so maybe that would be more complicated than it sounds.)

 (In reply to comment #3)
> I think if it just created the list in window-creation-time order rather than
> last-used-timestamp order then that would work as well. Though I'm not sure
> anything currently keeps track of that.

Startup-notifications should contain a timestamp, either as part of the ID or as a separate property. We'd obviously miss windows that are launched without startup id, but maybe that's not that much of an issue in practice?


> Another possibility would be to just allow each extension to provide a bit of
> data to be saved when the screensaver goes on, which would be passed back to it
> when it's re-enabled.

Well, enabling/disabling of extensions is implemented by calling corresponding extension methods, so extensions can certainly do that already.


> (Though then it would have to check if windows had been
> added or removed while it was disabled, so maybe that would be more complicated
> than it sounds.)

It's unlikely that this is the case while the screen is locked, but the extension may be disabled manually by the user and re-enabled after a month or so, so that'd definitively be needed.

I think whitelisting is a better option here, at least for the window list. For instance, I've noticed that maximized windows are resized when going into and out of the lock screen which is likely to be because this extension is changing struts as it gets enabled/disabled.

(In reply to comment #5)
> I think whitelisting is a better option here, at least for the window list.

Not sure - I've been pointed to a downstream bug[0], which is quite similar though unrelated to the lock screen.
(Of course the best option could still be to address both issues separately)

[0] https://bugzilla.redhat.com/show_bug.cgi?id=1025370

So, my personal opinion is that disabling and re-enabling the extension, however done, should try to change as minimally as possible.

Making the window list sort all existing windows by get_stable_sequence() on startup should work for this, if I understand it correctly.

I'm fine with adding a flag to "enable on lock screen" in meta.json, but I want to be very careful about this. Naive extensions like the places-menu should not be exposed on the lock screen, and that's why I disabled them.

Created attachment 274378 [details] [review]
window-list: Sort buttons by stable sequence

Currently the initial set of buttons is in stack/MRU order. To
avoid shuffling around the list each time it is disabled/re-enabled
(lock screen) or the group-mode settings changes, sort it by the
stable sequence.

Review of attachment 274378 [details] [review]:

::: extensions/window-list/extension.js
@@ +905,3 @@
+                    w1 = a1.get_windows().reduce(function(prev, cur) {
+                        return Math.min(prev, cur.get_stable_sequence());
+                    }, 0);

fyi Math.min can take more than two arguments. So this could be Math.min.apply(null, a1.get_windows().map(function(w) { return w.get_stable_sequence(); }));

which I suppose isn't much better... perhaps split this out as getStableSequenceForApp(); somewhere above?

Created attachment 274380 [details] [review]
window-list: Sort buttons by stable sequence

Attachment 274380 [details] pushed as d8eb227 - window-list: Sort buttons by stable sequence