These TODO comments are expected to be fixed ASAP, but until that happens let's minimize the errors in the console for development.
For https://github.com/vector-im/riot-web/issues/12877
These all aren't using componentDidMount because they do something which causes application instability if componentDidMount were used. Much of these calls are expected to move into constructors once they are converted to real classes.
Little bit of a mix of things in this one:
* Support variable-width dialogs. Default is fixed-width as before,
only UploadConformDialog is variable-width. Controlled by a prop
to BaseDialog.
* Fixes to the cancel 'x' - scale the mask image, tweak size & colour
* Colour & boldness of dialog titles
* Align the dialog title & cancel 'x'
* Remove gap between dialog buttons & right hand side of dialog(!)
* Round corners on dialogs
* Add grey border on image preview in upload confirm dialog
* and, squeezing in slightly randomly, finish the partially renamed
ChatInviteDialog to AddressPickerDialog.
This allows Webpack to insert the proper image URL after builds steps like
adding a hash and so on. The path you supply to `require` is relative to the JS
source file, just like any other would be.
Adds a New Recovery Method dialog which is shown when key backup fails because
of a version mismatch / version not found error.
The set up button in the dialog currently only marks a device as verified (via a
verification prompt) instead of the eventual restore and cross-sign flow, since
those pieces don't exist yet.
Signed-off-by: J. Ryan Stinnett <jryans@gmail.com>
* 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).
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.
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.
+ Upload Confirmation dialog would just change focus on ESC and not close
+ Keywords Dialog in UserSettings would also close UserSettings because event bubbled up
Fixes https://github.com/vector-im/riot-web/issues/3714https://github.com/vector-im/riot-web/issues/3714#issuecomment-297460620 :
> It's as if there are two dialogs and as one closes, the other one appears. For some reason matrix-org/matrix-react-sdk#822 is causing this.
> I've realised it's because the `priorActiveElement` is probably the button that opened the dialog. If this is focused and the enter key is released, this triggers a keyPress which fires once the dialog has closed and the button has been focused 😬 the BaseDialog only calls stopPropagation _onKeyDown.
The soln. was to submit the dialog as finished `onKeyUp`. This means the `priorActiveElement` is focussed after any key events that should be associated with the dialog.
