Aman-Mittal opened a new issue, #262:
URL: https://github.com/apache/fineract-backoffice-ui/issues/262
## Summary
`IonicOverlayAdapter.presentModal()` attaches its dismissal listener
**after** `await modal.present()`. Ionic resolves `present()` only once the
enter animation has finished, but it marks the overlay `presented` — and
therefore dismissible — before that animation starts. Anything that dismisses
the dialog inside that window (roughly 300 ms) fires `ionModalWillDismiss`
while `present()` is still pending, so nothing is listening yet, and the
one-shot event is lost.
The caller then awaits a promise that never settles. The dialog closes, and
the command it collected is never sent. No error, no toast, no console message
— the screen simply does nothing.
Every screen that collects input in a modal is affected, because they all go
through this one adapter method: group activate/close, the confirm dialogs, the
transaction forms, the session-expiry dialog.
## How it was found
The real-backend e2e suite hit it on CI. `group-membership.spec.ts` clicks
Confirm on the group activation dialog as soon as Playwright considers the
button actionable; the group then stayed Pending for the full 20 s assertion
window. It passed on a fast machine and failed on a loaded CI runner, where
dropped frames make a dialog look settled long before its animation has
finished — which is exactly the window this bug lives in.
## Reproduction
```ts
// Ionic's own ordering, from @ionic/core utils/overlays.ts
overlay.presented = true; // dismissible from here
await overlayAnimation(...); // ~300 ms
// present() resolves here
```
```ts
const modal = await modalController.create({ ... });
await modal.present(); // <- dismissal can already
have happened
modal.onWillDismiss().then(...); // <- listener attached too
late, never fires
```
A unit test reproduces it deterministically with a fake modal whose
`present()` resolves on demand: dismiss between `present()` starting and
resolving, and the result promise never settles.
## Expected
Confirming a dialog always delivers its result to the caller, whether or not
the opening animation has finished.
## Business Value
A user who confirms quickly — an experienced operator working through a
queue, or anyone on a slow machine where the animation drags — sees the dialog
close and assumes the action was taken. It was not. For group activation, loan
and savings commands, and teller settlements that means the operator believes a
financial action is recorded when nothing reached the platform, and they only
discover otherwise on a later reconciliation. Silence is the worst failure mode
here: an error would at least prompt a retry.
It also removes a whole class of test flakiness. Any e2e that opens a dialog
and confirms it is racing this window, which shows up as an unexplained
"nothing happened" failure that reproduces only under load.
## Notes
Fixed in #253 by subscribing `onWillDismiss()` before awaiting `present()`,
with a unit spec in
`src/app/core/adapters/overlay/ionic-overlay.adapter.spec.ts` that fails on the
old ordering.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
