{"version":"2.1.248","anchor":"dialog-requests-over-a-bridge-can-detach-and-wait-out-other-","canonical_anchor":"dialog-requests-over-a-bridge-can-detach-and-wait-out-other-","heading":"Dialog requests over a bridge can detach, and wait out other dialogs","tier":"notice","area":"Remote Control","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248\/e\/dialog-requests-over-a-bridge-can-detach-and-wait-out-other-","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.248","markdown":"### Dialog requests over a bridge can detach, and wait out other dialogs\n\nBridged dialogs can detach cleanly and stop timing out behind another open dialog.\n\n**What**\n\nA dialog request sent over the connection bridge can now come back as detached, which cancels the request cleanly instead of falling back to a default answer. Its timeout also no longer expires while a different blocking dialog is on screen: it re-arms, and re-arms again once that other dialog closes. Always on.\n\n**Details**\n\n- Backed by new shared state tracking whether a blocking dialog surface is mounted and which kind it is\n- Previously the handler only distinguished a completed reply from everything else\n\n**Evidence**\n\n`surfaceMounted`\n\n- Area: Remote Control\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5"}