The `TimelinePanel` uses two timers to coordinate read marker and read receipt
updates. When the read receipt timer fires, we advance the receipt and send the
latest state of both your receipt and marker to the server. When the read marker
timer fires, we advance the marker visually, but do not send anything to the
server: we were relying on the slightly different schedule of the read receipt
to actually send the updated read marker. This means there's a time window where
it's possible to visually advance the read marker without ever sending it to the
server (if you change rooms before the receipt timer fires again).
To simplify the behaviour here and ensure we always commit the updated marker
when we move it, this change sends an update to the server at the same time as
moving the marker.
It's possible this may improve some of the behaviour reported in
https://github.com/vector-im/riot-web/issues/12338.
The tag options are not implemented out of concern for diff size.
This splits the context menu classes out to a new "iconized" style which is common across a number of context menus, including the UserMenu.
Some of the badge/sublist styles had to change to better accommodate the menu icon lining up.
This also contains the framework required for https://github.com/vector-im/riot-web/issues/13961
This is per the designs. Animation doesn't feel required here.
Like the rest of this series, this rewrites a component to be more purpose-built to help match the designs and to solve the smallest possible problem.
This all-new component handles breadcrumbs a bit more smoothly for the app by always listening to changes even if the component isn't present. This allows the breadcrumbs to remain up to date for when the user re-enables breadcrumbs.
The new behaviour is that we turn breadcrumbs on once the user has a room, and we don't turn it back off for them.
This also introduces a new animation which is more stable and not laggy, though instead of sliding the breadcrumbs pop. This might be undesirable - to be reviewed.
Tabs now have IDs, and we use those IDs to open things. This doesn't do any conversion to typescript, and doesn't add the same feature to the room settings out of concern for the size of diff.
We were waiting only for the client to become logged in rather than
for setLoggedIn() to finish but then we were waiting for the first
sync to complete which is far longer. We need setLoggedIn to have
finished for crypto to be set up so we can query cross-signing keys,
so just wait for that anyway, the logic becomes a lot simpler and
we're waiting the same amount of time because we have to wait for
the first sync to finish. We can also download keys in parallel.
This is a work in progress, but covers the coarse areas. This uses all-new classes to better describe what everything is, and to reduce the number of selectors we keep track of.
This is primarily layout for the list and not actually the final structure. For example, some buttons are missing and other areas are not styled correctly - the idea in this commit was to get things roughly in the right place and work on it.
Though we consider the "room list" to mean the RoomList component specifically, the room list is actually the entire left panel as far as the user is concerned.
The new proposed designs for the room list modify the whole left panel, so we had might as well break it into new and old now instead of later. This "new" left panel is a bare-bones implementation and meant to only provide the absolute basic feature set to function for those who enable the experimental room list, for whatever reason. This is not intended to be a final implementation, or even remotely close to what it could be. An example of this is the lack of breadcrumbs. Given they are likely to change, they are excluded from this temporary skeleton completely.
This also includes a purple/pink bar between the tag panel and left panel. This is so we can, if needed, differentiate between people who made the mistake of turning on the experimental room list while the overall aesthetic makes it indistinguishable. Once the designs are moderately approved, we can (and definitely should) remove the hideous indicator.
- removed superfluous position and classes
- fixed compact view
- fixed event list summary avatar and text overlap
- fixed a problem where the mention list refuses to load.
https://github.com/matrix-org/synapse/issues/7512 means that (at least)
sometimes after clicking on the email validation link and being redirected
to riot, the server will claim the email identity auth stage is still incomplete.
This meant that we displayed the email identity UIA component but with an empty
email address, because we don't know that in the new session. Work around this by
assuming that if the email UIA component is being displayed but we don't have an
email address input, the link has been clicked and we're just waiting for the poll.
Also don't fire off an initial register request if we're already mid-UI-auth, because
that's confusing and unnecessary.
Also also remove unused requestingToken state.
Fixes https://github.com/vector-im/riot-web/issues/13434
This does a number of things (sorry):
* Estimates the type changes needed to the dispatcher (later to be replaced by https://github.com/matrix-org/matrix-react-sdk/pull/4593)
* Sets up the stack for a whole new room list store, and later components for usage.
* Create a proxy class to ensure the app still functions as expected when the various stores are enabled/disabled
* Demonstrates a possible structure for algorithms
Like a5f3318f3b, this proves that the new dispatcher conversion works for fire-and-forget style dispatches too. This is another obvious-if-broken and generally safe conversion to make.
Other actions which can be dispatched this way have been excluded for reasons mentioned in the Action enum's comments.
This is a relatively obvious dispatch action that doesn't require a lot of complicated type definitions, so should be a good candidate to prove the thing works. If for some reason the thing stops working, we've done something wrong.
This also adds a bit of generic types to the dispatch call so we don't confuse the tsx parser by using `dis.dispatch(<ViewUserPayload>{...})` as it thinks that's supposed to be a component. We still get type safety, and the thing remains happy with the generics approach.
Fixes https://github.com/vector-im/riot-web/issues/13479
This looks to have been caused by something to do with the app load order, though where is a mystery. The view change seems to fire for the same page type despite a dispatch that says to change the view type.
Instead of debugging it too much further, we'll just patch around it.
This commit also makes the settings link use a more safe approach to viewing the user info - not going through the dispatcher means we are at the mercy of browser behaviour when we already have a loop which deals with this.
The key backup reminder was being shown too eagerly in cases when we hadn't
actually checked with the homeserver on key backup status. This changes to only
show the reminder when we're sure a backup doesn't exist.
Fixes https://github.com/vector-im/riot-web/issues/13404
This fix isn't perfect. Currently the scroll view is
slightly smaller than the list of rooms. I think it has something
to do with the how the heigh is calculate in js, considering it has
some assumptions about the height of each bar and the padding. However
room items are the only things which change with respect to the root
value. Therefore the item list is actually taller than the computed
pixel value of the list converted to rems.
I'll look into it.
