The js-sdk's placement of the notification change was unreliable and could cause stuck notifications. The new location (piggybacking the Notifier) is a lot more reliable.
The tinting has been changed fairly invasively in order to support the changing of the `fill` attribute. What was happening before was the `fill` property would happily get set to the forced color value, but when it came time to reset it it wouldn't be part of the colors array and fail the check, therefore never being changed back. By using a second field we can ensure we are checking the not-forced value where possible, falling back to the potentially forced value if needed.
In addition to fixing which color the Tinter was checking against, something noticed during development is that `this.colors` might not always be a set of hex color codes. This is problematic when the attribute we're looking to replace is a rgb color code but we're only looking at `keyHex` - the value won't be reset. It appears as though this happens when people use custom tinting in places as `this.colors` often gets set to the rgb values throughout the file. To fix it, we just check against `keyHex` and `keyRgb`.
Fixes https://github.com/vector-im/riot-web/issues/3383
This achieves the result by counting up the number of highlights across all rooms and setting that as the badge above the icon. If there are no highlights, nothing is displayed. The red highlight on the bell is done by abusing how the Tinter works: because it has access to the properties of the SVG that we'd need to override it, we give it a collection of colors it should use instead of the theme/tint it is trying to apply. This results in the Tinter using our warning color instead of whatever it was going to apply.
The RightPanel now listens for events to update the count too, otherwise when the user receives a ping they'd have to switch rooms to see the change.
Fixes https://github.com/vector-im/riot-web/issues/5689
Some dialogs had their own CSS that prevented the buttons from being placed in the right spot. This has been fixed by using a generic standard for the buttons. The only strange dialog that needed more CSS was the devtools dialog due to the header.
Not all dialogs have been checked - I spot-checked about half of them and verified the CSS manually on an established account. It's hard to get at all the dialogs without convoluted testing.
With this more of the
controls that look like buttons can be operated via the keyboard and
navigated to by screen reader users. This includes editor buttons such
as File upload, Audio / Video call, Right pannel hide button, Jump to
the bottom timeline button, and some more buttons found in the user
settings.
Also I have added alt texts to some images that in turn label buttons
which these happen to be packed in and removed some untranslated alt
texts from decorative non-actionable images that might add more
verbosity when talking about screen reader user experience.
ActiveWidgetStore is now reponsible for removing the current
persistent widget from the store if it's been removed from whatever
room it was in. As per comment, this leaves us with the store updating
itself in this case but in all other cases, views call setters on the
store to update its state. We should make it so the store keeps itself
up to date and views aren't responsible for keeping the store up to date.
The store now emits events so it can notify PersistentApp when it changes.
Fixes https://github.com/vector-im/riot-web/issues/7076
As per https://github.com/matrix-org/matrix-doc/issues/1354
This is whitelisted to only jitsi widgets for now as per comment,
mostly because any widget that we may make always-on-screen we need
to preemptively put in a PersistedElement container, which is
unnecessary for any other widget.
Apologies that this does a bunch of refactoring which could have
been split out separately: I only discovered what needed to be
refactored in the process of doing this.
Fixes https://github.com/vector-im/riot-web/issues/6984
This reverts a fix to EditableText introduced in
https://github.com/matrix-org/matrix-react-sdk/pull/1445
which introduced a bug that causes room name and topic to
reset when UserSettings is rerendered because
`initialValue != this.value`
This also fixes the same bug originally fixed by #1445:
>fix entering the same thing twice (which had the bug of not
>emptying the "new" field)
which, in other words meant that clicking "+" when adding a room
alias would not reset the contents of the bottom-most alias in the
list.
The fix is to increment the `key` of the element, causing a new
instance to be mounted instead of passing new props to the existing
one.
Widgets would sometimes briefly re-appear after having been deleted.
This was because of the following race:
* User presses delete, send POST req, we set `deleting`. Widget hides.
* POST request completes, we unset `deleting` so widget unhides.
* State event comes down sync so widget hides again.
This fixes this by introducing `waitForRoomWidget` and using it to
wait until the state event comes down the sync until clearing the
`deleting` flag.
Since we now have `waitForRoomWidget`, this also uses it when adding
a widget so the 'widget saved' appears at the same time the widget
does.
Alternative integration managers may wish to also wrap widgets to supply a better user experience. With the previous code, it was not possible to use the integrations_widgets_urls configuration option (described in AppTile). AppPermission should use the same logic to determine if a widget is being wrapped, so it can display a helpful URL for the user (instead of the wrapper URL).
Signed-off-by: Travis Ralston <travpc@gmail.com>
