A screen handle was used while its screen is not in focus — the screen on
top: back, an action or an edge (for an item: while its host is not in
focus), or a trail. Only the screen in focus acts, as in the app, where a
person cannot act on a screen another one hides.
reason answers "does waiting help":
covered — the screen will be in focus again, and the same handle will
work, once what covers it is closed, so the program keeps using its own
variable. It is given only when the cover can actually be removed: the
frame is held by a stack, and in the stack on screen the navigation chain
from the frame's start is exactly the entries the frames from it to the top
wrote. A bottom tab left for another one is covered too: switching back
puts its stack, and its handle, in focus again.
navigation-moved — the handle will never work again: its frame is closed
or replaced (the screen was opened again as a new frame, an inner tab or an
updating action's answer replaced it), or the navigation chain no longer
ends with the entries the frames wrote — another entry, or the same
entry showing another screen (a raw navigation event, a raw top-tab switch
or a brick moved the app elsewhere) — so the wire would show a chain the
app cannot produce.
A defect, not a typed failure, because of how the stack can move: every
transition that puts a frame over this one or moves its chain entries — an
edge or action that opens a screen, the launch, logIn escalating to a code
screen, OpenChallenge bringing a challenge step, a retrace, back — hands
the caller the new top (or its outcome) from the very call that moved it, and
a failed transition is rolled back, leaving the old handle on top. The
server may decide what opens, but the caller is always told by the call that
opened it. So acting on the old handle afterwards ignores what the program was
given, or is the program's own raw navigation (a brick, a navigation event):
the call dies with this error and no typed channel carries it. A path that
moved the stack without telling the caller would be server-decided and typed;
none exists.
The message is written by the stack (ensureOnTop) from what covers the
screen or why it is gone, so it names the screen in focus and only advises an
action that exists: a left tab is switched back to, a pushed screen is closed
by back() or its closing action, an overlay by its own closing step; a
closed or replaced handle is replaced by the one the call that closed it
returned; after a raw navigation no handle is offered.
A screen handle was used while its screen is not in focus — the screen on top:
back, an action or an edge (for an item: while its host is not in focus), or a trail. Only the screen in focus acts, as in the app, where a person cannot act on a screen another one hides.reasonanswers "does waiting help":covered— the screen will be in focus again, and the same handle will work, once what covers it is closed, so the program keeps using its own variable. It is given only when the cover can actually be removed: the frame is held by a stack, and in the stack on screen the navigation chain from the frame's start is exactly the entries the frames from it to the top wrote. A bottom tab left for another one is covered too: switching back puts its stack, and its handle, in focus again.navigation-moved— the handle will never work again: its frame is closed or replaced (the screen was opened again as a new frame, an inner tab or an updating action's answer replaced it), or the navigation chain no longer ends with the entries the frames wrote — another entry, or the same entry showing another screen (a raw navigation event, a raw top-tab switch or a brick moved the app elsewhere) — so the wire would show a chain the app cannot produce.A defect, not a typed failure, because of how the stack can move: every transition that puts a frame over this one or moves its chain entries — an edge or action that opens a screen, the launch,
logInescalating to a code screen,OpenChallengebringing a challenge step, a retrace,back— hands the caller the new top (or its outcome) from the very call that moved it, and a failed transition is rolled back, leaving the old handle on top. The server may decide what opens, but the caller is always told by the call that opened it. So acting on the old handle afterwards ignores what the program was given, or is the program's own raw navigation (a brick, a navigation event): the call dies with this error and no typed channel carries it. A path that moved the stack without telling the caller would be server-decided and typed; none exists.The message is written by the stack (
ensureOnTop) from what covers the screen or why it is gone, so it names the screen in focus and only advises an action that exists: a left tab is switched back to, a pushed screen is closed byback()or its closing action, an overlay by its own closing step; a closed or replaced handle is replaced by the one the call that closed it returned; after a raw navigation no handle is offered.