Permission-gated call made before the app window is registered is dropped unanswered and denied; blocking client then panics on Xous(AccessDenied)

[tobyjaguar]

Environment: KeyOS v1.4.0 (eb2c2edb3) hosted simulator; third-party-class sideloaded app built in-tree with cargo xtask build-app.

Steps: in app_main, before ui.run() has started (or from a worker thread started immediately at launch), call a grantOnFirstUse message such as Security::app_seed() (GetAppSeed).

What happens: the consent prompt is never shown; gui-server logs

gui_server::permissions: permission prompt for request 0 dropped unanswered; denying

and the blocking client in server/src/blocking_archive.rs:154 unwraps the resulting Xous(AccessDenied), so the calling thread panics:

thread '<unnamed>' panicked at server/src/blocking_archive.rs:154:41:
called `Result::unwrap()` on an `Err` value: Xous(AccessDenied)

Making the same call about 1.5 s after the event loop is running (window registered, app in the foreground) shows the prompt and works.

Expected / suggestions: either queue the prompt until the requesting app has a registered window, or document in the SDK that permission-gated calls must wait until the app is in the foreground. Independently, send_blocking_archive could return the xous error to the caller instead of unwrapping, so a denied permission is recoverable in-app (there is a try_send_blocking_archive, but the typed API methods such as Security::app_seed do not expose it).

[badicsalex]

Security::app_seed (and friends) used to be practically infallible, hence the unwrap().

Having them still unwrap() while they can fail with a permission error was definitely and oversight, we need to re-introduce the
"try_" version for these (can't really change the result type without affecting backwards compatibility, so we will probably just deprecate the non-try versions).

The "can only request permissions while in the foreground" is a separate issue that we will look into.

[tobyjaguar]

Thanks, the try_ variants would be exactly what we need: a denied prompt should be recoverable in-app (we show a retry button) rather than a dead thread.

One request on the foreground rule: whatever the eventual behaviour, could it go into the SDK docs? It is the first thing a third-party developer hits when they request the app seed at startup, and the failure is silent from the app's point of view (the prompt never appears and the call fails). We work around it with a short timer after the event loop starts.

[badicsalex]

The "foreground rule" is not intended. The app should be able to get permissions as soon as it starts, no matter the gui state. In fact it should work for fully non-gui stuff too.

Fortunately we are working on a structurally similar thing right now (cc @georgesFoundation), so we can feed two birds with one scone

[badicsalex]

In the meantime, you can subscribe to the ::Visible event with a custom event handler with AppContext.set_input_handler

(We should probably add that struct to the API documentation)