bug : sweet alert popup blocks user input on "its" area even after disappearing

When a form is set to Use SweetAlert a popup is automatically diplayed when the Save button is clicked: “Data Modified”.
The alert, as expected, disappears after a few seconds.

The issue is that the alert it’s actually still on the page, even if not visible anymore, thus if it was diplayed on top of some user input elemens (e.g. a text box), those elements are now not responding to user input anymore (i.e. can’t select the text box for editing its content).

All input elements that were not “covered” by SwettAlert keep working.

With the default setting “SweetAlert position using Toast” set to “Top Right”, the issue is not easily noticable because in that area (top right) it’s vey unlikely to have user input elements.
The issue is much more likely to happen if the alert position is set to “Center”.

That the cause of the issue is the SweetAlertis is easily identifiable:

  1. In the SC IDE, set the form layout and SweetAlert options so that the toast message will pop up over e field text box
  2. Run the form
  3. Press the Save button to save the record.
  4. After the popup alert has disappeared, you’ll notice that editing the text box that was covered by Sweet Alert is not possible anymore (this is the bug)
  5. Inspect the page with the browser by right clicking where the SweetAlert was displayed.
  6. Find and remove the SweetAlert div (<div class=“swal2-container swal2-top-end swal2-fade swal2-shown” style=“overflow-y: auto;”>…</div>).
  7. Editing the text box that was blocked before is now possible.

@NetMake can you please fix this?

Having the same issue. Can be recreated this way:

  1. Create a simple Grid application
  2. Add a record to table
  3. Return to grid display
  4. Select record just added
  5. Delete record - Message “Record deleted sucessfully” displayed over grid “back” button. Message disappears.
  6. Grid "back’ button now unresponsive to clicks.

Workaround is to move message display elsewhere however Robydago is correct, wherever moving it will cause UI elements underneath to become unresponsive.

Thanks

hi,

I also confirm the bug.

excellent explanation of how to reproduce it

Confirm. I have the same experience. I had to move the toast position from the center to the bottom because of this bug.