The previous algorithm had a bug where it was getting stuck on the power level comparison, leaving the memberlist incorrectly ordered. The new algorithm uses less branching to try and walk through the different cases instead. Additionally, the steps used to determine the order have changed slightly to better represent an active member list.
This commit also includes changes to try and re-sort the member list more often during presence changes. Events are not always emitted, however. This may be a js-sdk bug but appears to happen prior to these changes as well.
Fixes https://github.com/vector-im/riot-web/issues/6953
If the current device hasn't verified the device that created the account's
current key backup version, then the current device is won't use the key backup.
This change adjusts an existing in-room reminder to do the right thing for this
case by allowing the user to verify the device that created the key backup.
Fixesvector-im/riot-web#7902.
It's possible to get errors when fetching commits (for example, if the rate
limit is exceeded), so this will handle the error case and display it instead of
an infinite spinner.
Signed-off-by: J. Ryan Stinnett <jryans@gmail.com>
a view_right_panel_phase is dispatched by RoomHeaderButtons
on view_room, which was triggering this to show the panel again.
Check the fromHeader flag just like when hiding the panel so
only room header buttons can hide or show the right panel
check overflow on mount
restore size on query change (in case a sublist appeared)
check overflow when updating rooms
avoid duplicating for restoring size and checking overflow
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>
Adds UI control for 3 hidden notification rules:
* Messages containing @room
* Encrypted one-to-one messages
* Encrypted group messages
This should help to clarify some mysterious notification behavior, as it wasn't
obvious that these rules existed.
Fixesvector-im/riot-web#7833.
Signed-off-by: J. Ryan Stinnett <jryans@gmail.com>
They are now independent of each other. If both are specified in the config, the user will see an error and be prevented from logging in. The expected behaviour is that when a default server name is given, we do a .well-known lookup to find the default homeserver (and block the UI while we do this to prevent it from using matrix.org while we go out and find more information). If the config specifies just a default homeserver URL however, we don't do anything special.
This adds an in-room reminder above the message timeline to set up Secure
Message Recovery so that your keys will be backed up. If you try to ignore it,
an additional dialog is shown to confirm.
Fixesvector-im/riot-web#7783.
Signed-off-by: J. Ryan Stinnett <jryans@gmail.com>
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/4369
Previously the RoomSubList would filter its list of rooms to verify that the incoming call belongs to it. This causes problems when the sub list is being told some rooms don't exist (ie: the list is filtered). It is trivial for the RoomList to instead track which RoomSubList (tag) it should be handing the call off to so we do that instead now. The RoomSubList trusts that the caller has already filtered it and will render the IncomingCallBox if it has an incoming call.
Fixes https://github.com/vector-im/riot-web/issues/7724
The `default_server_name` from the config gets displayed in the "Login with my [server] matrix ID" dropdown when the default server is being used. At this point, we also discourage the use of the `default_hs_url` and `default_is_url` options because we do an implicit .well-known lookup to configure the client based on the `default_server_name`. If the URLs are still present in the config, we'll honour them and won't do a .well-known lookup when the URLs are mixed with the new server_name option. Users will be warned if the `default_server_name` does not match the `default_hs_url` if both are supplied. Users are additionally prevented from logging in, registering, and resetting their password if the implicit .well-known check fails - this is to prevent people from doing actions against the wrong homeserver.
This relies on https://github.com/matrix-org/matrix-js-sdk/pull/799 as we now do auto discovery in two places. Instead of bringing the .well-known out to its own utility class in the react-sdk, we might as well drag it out to the js-sdk.
