Watch
1
0
Fork
You've already forked souveraine
0

lock: dismiss the boot bloom on a level, not only on an edge

bootBloomActive defaults true on every scene construction and bootDismissed
resets with it, but the only thing that cleared them was the secure EDGE. A
scene reload during an already-secure lock never moves `secure`, so nothing
cleared the bloom and the phone sat under a full-screen white overlay until the
shell was restarted. Casey hit it and reported it as "the hyprland error
screen"; `grim` returned a solid white 9KB frame, and hyprctl configerrors was
empty the whole time.

Third instance of this exact shape: locked_ack after a sessiond restart, the
ChargeRate stale-scene reload, and now this. Check the level at construction as
well as the edge.

Deliberately not a timeout — a bloom outliving its reason is a bug to locate.
This commit is contained in:
Fimeg 2026-07-29 10:54:45 -04:00
commit 0a635ff984

View file

@ -121,12 +121,23 @@ Scope {
onSecureChanged: {
GlobalStates.screenLockSecure = secure;
console.log("[lock] session lock secure=" + secure);
if (secure && !root.bootDismissed) {
root.bootDismissed = true;
GlobalStates.bootBloomActive = false;
}
root.dismissBloomIfSecure();
}
// The dismissal above is an EDGE, and a scene reload is exactly the
// case where the edge is in the past. `GlobalStates.bootBloomActive`
// defaults to true on every scene construction and `bootDismissed`
// resets with it, but a reload during an already-secure lock never
// moves `secure` so nothing ever cleared the bloom and the phone sat
// under a full-screen white overlay until the shell was restarted.
// Observed 2026-07-29: a reload at 10:44:10 with no secure transition
// after it, and a solid white `grim` capture.
//
// Same shape as the locked_ack edge that never re-fired after a
// sessiond restart, and as the ChargeRate stale-scene reload. Check the
// LEVEL at construction as well as the edge.
Component.onCompleted: root.dismissBloomIfSecure()
// The compositor can end our lock without us asking: ext-session-lock
// `finished` (denied because another client held it) makes quickshell
// drop `locked` to false C++-side. Our request bool never hears about
@ -144,6 +155,17 @@ Scope {
}
}
// Idempotent, and deliberately NOT a timeout. A bloom that outlives its
// reason is a bug to locate, not something to paper over with a timer if
// this is still up while the lock is secure, the caller is missing and the
// fix belongs where the call is missing.
function dismissBloomIfSecure() {
if (!lock.secure || root.bootDismissed)
return;
root.bootDismissed = true;
GlobalStates.bootBloomActive = false;
}
function lock() {
if (Config.options.lock.useHyprlock) {
Quickshell.execDetached(["bash", "-c", "pidof hyprlock || hyprlock"]);