UIKit modal: a viewSubmit response with no `type` field fails to close the modal on mobile (regression from #7057)

Aperta Adatta ai principianti
  • Qualcosa non va?
#7,503 3 commenti 1 reazione 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

@erikurt9 ci sta già lavorando.

Dal 1/8/2026.

  • #7537 di @erikurt9 — aperta

Valutazione

Difficoltà
2/5
Tempo stimato
1-3 ore
Idoneità per principianti
76/100
Tipo di issue
Bug
Chiarezza
Specificata chiaramente
Stato di attività
Tranquilla
Stack tecnologico
react-native, typescript
Ambito
mobile

Direzione di ricerca

Leggi app/lib/methods/actions.ts e app/containers/UIKit/interactionAdapters.ts, quindi traccia triggerSubmitView in app/lib/methods/triggerActions.ts. Verifica che una risposta riuscita senza type venga gestita come modal.close, mentre le stringhe type sconosciute continuino a fallire, e conferma che la modale si chiuda per la risposta di successo semplice documentata su mobile.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

type: bug

When a Rocket.Chat App responds to a viewSubmit UIKit interaction with a bare
success response ({ "success": true }, no type field — this is what
apps-engine's UIKitInteractionResponder.successResponse() produces, and is a
documented valid response shape for "done, nothing more to render"), the modal
fails to close on the mobile app. No error is shown to the user; the submit
spinner simply stops and the form stays open.

This worked correctly before PR #7057 ("feat: Voice message blocks"), and still
works correctly on the desktop/web client.

Steps to reproduce
  1. Build (or use) a Rocket.Chat App that opens a UIKit modal (e.g. via a slash
    command) and, on viewSubmit, returns
    context.getInteractionResponder().successResponse().
  2. Open the modal on the mobile app and tap Submit.

Expected: the modal closes, same as it does on desktop/web.
Actual: the modal stays open. Nothing is shown to the user — no error, no
update — the loading indicator just clears.

Root cause

In app/lib/methods/actions.ts, triggerAction() parses the response body and
does:

const { type: interactionType, ...data } = parsed;
const modalType = toServerModalInteractionType(interactionType ?? '');
if (!modalType) {
throw new Error(Unknown modal interaction type: ${interactionType ?? 'undefined'});
}

toServerModalInteractionType (app/containers/UIKit/interactionAdapters.ts) is
a strict allow-list of 'modal.open' | 'modal.update' | 'modal.close' | 'errors'.
A bare { success: true } response has interactionType === undefined, so
toServerModalInteractionType('') returns null, and the code above throws.

That exception propagates out of triggerAction, through triggerSubmitView
(app/lib/methods/triggerActions.ts), which has no try/catch of its own — so
its Navigation.back() call (gated on triggerAction's resolved value) is
never reached. The exception is only caught by ModalBlockView.submit()'s
outer catch (e) { /* do nothing */ }, which swallows it silently.

Before #7057, triggerAction/handlePayloadUserInteraction treated any
unrecognized or missing type as an implicit ModalActions.CLOSE by fallthrough
(no allow-list, no throw), so this exact response used to close the modal.

Cancel is unaffected because ModalBlockView.cancel() calls Navigation.back()
unconditionally before making the network call, so the same exception (thrown
inside triggerCancel → triggerAction) no longer matters by the time it fires.

Web is unaffected because ActionManager.emitInteraction's finally block
closes the view on any response type outside an exclusion list
(errors/modal.update/contextual_bar.update), rather than requiring the
type to be on an allow-list.

Proposed fix

In triggerAction, treat a successful response with no type field as an
explicit modal.close before consulting the allow-list, instead of throwing:

const { type: interactionType, ...data } = parsed;
if (interactionType === undefined) {
return ModalActions.CLOSE;
}
const modalType = toServerModalInteractionType(interactionType);
if (!modalType) {
throw new Error(Unknown modal interaction type: ${interactionType});
}

This restores the old behavior for the specific case that regressed, without
weakening the throw for a genuinely unrecognized type string.

Environment

  • Rocket.Chat.ReactNative: develop (reproduced against a build including PR #7057)
  • Rocket.Chat Server: 8.6.0
  • Platform: Android v15 (code path is platform-independent, likely affects iOS too)
  • Apps-Engine version: 1.64.0
Lingua principale
TypeScript
Stelle
2.4k
Fork
1.5k
Merge medio
1g 15h
PR unite (30g)
29

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di RocketChat/Rocket.Chat.ReactNative

Tutte le issue di RocketChat/Rocket.Chat.ReactNative

Issue simili

Altre issue su TypeScript

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.