the overflow/underflow events are not always reliable in nooverlay
browsers (FF), so forward the checkOverflow call we need anyway
for the scroll indicator gradients to see if we need to do the
margin trick for the on-hover scrollbar we use in nooverlay browsers.
this fixes on hover jumping in a subroomlist
Last friday a child <div> was added inside the ResizeHandle component,
which made the parentElement/classList checks fail on the event.target
here. This would only fail (and select all the text) when dragging exactly on
the grey line (the div), not the transparent margin around it.
use closest to make sure we have the root element of the handle.
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>
If creating a new key backup version succeeds but backing up to it fails, delete
the version to avoid surprises. In addition, this converts the creation of a new
key backup to async / await style.
Signed-off-by: J. Ryan Stinnett <jryans@gmail.com>
Regular expression objects are stateful, and the global flag interferes badly with the expression. A valid call can cause it to act like a flip flop instead of a stateless test.
the idea is that it will keep a RoomViewStore for every
room on the screen, and also keep track of which one is
the current one.
For now, it just replicates the existing functionality of
having just 1 room on the screen.
Since the RoomViewStore just has access to a local dispatcher
and not the global anymore, all dispatching of actions
needs to be moved to the OpenRoomsStore, so room alias resolving,
event forwarding, ... is moved there.
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>
The only behaviour that should have changed here is that
presence is also set to online when switching back to the
tab/window.
Presence is not set to unavailable when coming back to the window/tab,
as that might be a bit invasive, but only when timing out.
Before, UserActivitity emitting actions meant that the user had very recently interaction with their hardware.
Now it means they are likely looking at the app.
You can attach a timer that is aborted when we think the user
stops looking at the page
(or hasn't touched their hardware for 2 minutes).
This works better than the previous approach for larger timeouts,
like the 30s we're about to implement for out-of-view RMs
When I was talking to Matthew about this the other day, we couldn't think of a
good reason why we should preserve the HS URL at logout. It introduces the
problem that, if a client is redirected after login as per MSC1730, and then
you log out, you'll then get a login screen for the wrong server.
So basically there's no reason to have an mx_hs_url/mx_is_url without an access
token, and we can remove the stuff which preserves it, and the stuff that
attempts to restore it.
This was noticed as a problem after `Unread.doesRoomHaveUnreadMessages` started being called a lot more frequently. Down the call stack, `shouldHideEvent` is called which used to call into the `SettingsStore` frequently, causing performance issues in many cases. The `SettingsStore` tries to be as fast as possible, however there's still code paths that make it less than desirable to use as the first condition in an AND condition. By not hitting the `SettingsStore` so often, we can shorten those code paths.
As for how much this improves things, I ran some profiling before and after this change. This was done on my massive 1200+ room account. Before it was possible to see nearly 2 seconds spent generating room lists where 20-130ms per room was spent figuring out if the room has unread messages. Afterwards, the room list was generating within ~330ms and each unread check taking 0-2ms. There's still room for improvement on generating the room list, however the significant gains here seem worth it.
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.
Currently, any error in the `GroupStore`s several requests can cause the whole
`GroupView` component to hide and be mark the group as failed to load.
Since it is known that group members may fail to load in some cases, let's only
show failed to load for the whole group when the summary fails.
This also strengthens the `GroupView` test by ensuring we wait for multiple
updates for checking results.
Signed-off-by: J. Ryan Stinnett <jryans@gmail.com>
