* Make it use BaseDialog / DialogButtons (also gives it has a top-right 'x' &
escape to cancel works)
* Stop misusing the 'danger' CSS class on the buttons. There is nothing dangerous
about submitting logs.
* Continued campaign against 'Click here' links.
Fixes https://github.com/vector-im/riot-web/issues/6622
* Make the 'delete my data' button not the default
* Make it red
* Give it a confirmation dialog
* Remove the 'cancel' button: what does it mean to cancel an error?
In this case, it tried again and almost certainly got the same error.
* Remove the top-right 'x' and don't cancel on esc for the same reason.
* Move 'send bug report' to a button rather than a 'click here' link
* Add a 'refresh' button which, even if it's no more likely to work,
will at least look like it's doing something (it's mostly so if you
don't have a bug report endpoint, there's still a button other
than the one that deletes all your data).
* Make the 'delete my data' button not the default
* Make it red
* Give it a confirmation dialog
* Remove the 'cancel' button: what does it mean to cancel an error?
In this case, it tried again and almost certainly got the same error.
* Remove the top-right 'x' and don't cancel on esc for the same reason.
* Move 'send bug report' to a button rather than a 'click here' link
* Add a 'refresh' button which, even if it's no more likely to work,
will at least look like it's doing something (it's mostly so if you
don't have a bug report endpoint, there's still a button other
than the one that deletes all your data).
The user might (probably does) have a session even if we haven't actually tried
to load it yet, so wrap the whole loadSession code in the error handler we were
using for restoring sessions so we gracefully handle exceptions that happen
before trying to restore sessions too.
Remove the catch in MatrixChat that sent you to the login screen. This is
never the right way to handle an error condition: we should only display the
login screen if we successfully determined that the user has no session, or
they explicitly chose to blow their sessions away.
Everywhere else, onFinished takes a boolean indicating whether the
dialog was confirmed on cancelled, and had function that were
expecting this variable and getting undefined.
Fix a number of failures that meant the excellent error handling
we had for failing to restore a session didn't work.
1. .catch on the promise rather than try/catch: it's async
2. Explicit cancel method in SessionRestoreErrorDialog that invokes
onFinished with `false` because even with the catch fixed, this
was getting the event as its first arg which is truthy, so
clicking cancel still deleted your data.
3. DialogButtons: Don't pass onCancel straight into the button event
handler as this leaks the MouseEvent through as an argument.
Nothing is using it and it exacerbates failures like this
because there are surprise arguments.
Fixes https://github.com/vector-im/riot-web/issues/6616
leaving it in the Modal manager.
We are using Modal manager to load other components not just BaseDialog
and its subclasses and they might require different keyboard handling.
Also depend on focus-trap-react rather than react-focus-trap for locking
keyboard focus inside the dialog. The experience is much nicer and even
the FocusTrap element it-self no longer gains the focus.
On a side note using the FocusTrap element outside the dialog (on
its parent) stops it from working properly.
- Wrapped all the modals inside a react-focus-trap component disabling
keyboard navigation outside the modal dialogs
- Disabled our custom key handling at dialog level. Cancelling on esc
key is now handled via FocusTrap component.
- Removed onEnter prop from the BaseDialog component. Dialogs that
submit data all now embed a form with onSubmit handler. And since
keyboard focus is now managed better via FocusTrap it no longer makes
sense for the other dialog types. Fixes
https://github.com/vector-im/riot-web/issues/5736
- Set aria-hidden on the matrixChat outer node when showing dialogs to
disable navigating outside the modals by using screen reader specific
features.
Don't pop up the dialog as soon as we can't send a message.
Also removes dispatches used to keep the RoomStatusBar up to date.
We can get the same events straight from the js-sdk via the
pending events event.
rather than having to have the error message passed in.
This is in preparation for not having the dialog pop up straight
away when a message isn't sent so we don't have to keep the error
object knocking around somewhere.
