All of the anchors were pointed at `#` which, when clicked, would trigger a hash change in the browser. This change races the change made by the screen handling where the screen handling ends up losing. Because the hash is then tracked as empty rather than `#/login` (for example), the state machine considers future changes as no-ops and doesn't do anything with them.
By using `preventDefault` and `stopPropagation` on the anchor click events, we prevent the browser from automatically going to an empty hash, which then means the screen handling isn't racing the browser, and the hash change state machine doesn't no-op.
After applying that fix, going between pages worked great unless you were going from /login to /home. This is because the MatrixChat state machine was now out of sync (a `view` of `LOGIN` but a `page` of `HomePage` - an invalid state). All we have to do here is ensure the right view is used when navigating to the homepage.
Fixes https://github.com/vector-im/riot-web/issues/4061
Note: the concerns in 4061 about logging out upon entering the view appear to have been solved. Navigating to the login page doesn't obliterate your session, at least in my testing.
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
All of the anchors were pointed at `#` which, when clicked, would trigger a hash change in the browser. This change races the change made by the screen handling where the screen handling ends up losing. Because the hash is then tracked as empty rather than `#/login` (for example), the state machine considers future changes as no-ops and doesn't do anything with them.
By using `preventDefault` and `stopPropagation` on the anchor click events, we prevent the browser from automatically going to an empty hash, which then means the screen handling isn't racing the browser, and the hash change state machine doesn't no-op.
After applying that fix, going between pages worked great unless you were going from /login to /home. This is because the MatrixChat state machine was now out of sync (a `view` of `LOGIN` but a `page` of `HomePage` - an invalid state). All we have to do here is ensure the right view is used when navigating to the homepage.
Fixes https://github.com/vector-im/riot-web/issues/4061
Note: the concerns in 4061 about logging out upon entering the view appear to have been solved. Navigating to the login page doesn't obliterate your session, at least in my testing.
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.
The classes on the search box input were changed without updating the focusing
loop in the room filter which used one of these classes as a boundary condition.
This led to a case that could loop forever.
Regressed by #2267.
Fixesvector-im/riot-web#7926.
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
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
Christopher Medlin