On registering, we showed a spinner, and then another spinner on
top of the spinner, which led to an interesting spinner-in-box
effect.
Suppress the second type of spinner when we know we already have one.
https://github.com/matrix-org/matrix-react-sdk/pull/3101 meant we
don't get logged straight in after registering if using an email
address, but this was the point at which we made a chat with the
welcome user. Instead, set a flag in memory that we should try &
make a chat with the welcome user for that user ID if we get a
session for them.
Of course, if the user logs in on both tabs, this would mean each
would make a chat with the welcome user (although actually this
was a problem with the old code too). Check our m.direct to see if
we've started a chat with the welcome user before making one (which
also means we have to make sure the cached sync is up to date...
see comments).
You now don't get automatically logged in after finishing
registration. This makes a whole class of failures involving race
conditions and multiple devices impossible.
https://github.com/vector-im/riot-web/issues/9586
This always clear the login busy state after .well-known discovery without
waiting for the resulting server config. This is important for the case where
the HS that a full MXID resolves to matches the default HS, as without it we'd
be stuck in a busy state forever.
Fixes https://github.com/vector-im/riot-web/issues/10014
This aligns the message context menu on either the top or the bottom of the
button that triggers, depending on which side has more space available to fit
the menu.
Fixes https://github.com/vector-im/riot-web/issues/9624
This changes the message context menu to align the right edge of the menu with
the right edge of the button that opens it, which should keep all menu options
inside the viewport, even if they are very wide.
Part of https://github.com/vector-im/riot-web/issues/9624
For context menus without chevrons, this changes the menu components to still
set default styles that align the menu based on the edges used to specify the
menu's position. This is not intended to change the positioning of any existing
menus.
This changes the message action bar to force an update after an event decrypts,
since it's quite likely that changes the set of available actions.
Fixes https://github.com/vector-im/riot-web/issues/9991
When the user was on an invite page and clicked the sign up/sign in
buttons, remember that invite so we can show it again after they're
done signing up/in.
https://github.com/vector-im/riot-web/issues/9816
Riot was always saying the email address that the invite was sent
to was not associated with your account.
Two fixes here:
1. We mounted RoomPreviewBar with no invitedEmail prop and then
changed the prop later, but RoomPreviewBar only checked for it
on mount. Make sure we re-check when the props change.
2. Pass oobData through RoomPreviewBar because we need to pass it
to the RoomAvatar for 3pid invites.
https://github.com/vector-im/riot-web/issues/9816
This makes the reaction row buttons take the current count as prop as an easy
way of ensuring they always trigger an update when the count changes.
Fixes https://github.com/vector-im/riot-web/issues/9954
This performs liveliness checks on the auth pages to try and show a friendlier error. Earlier checks in the app startup are expected to not block the app from loading on such failures.
See https://github.com/vector-im/riot-web/issues/9828
See https://github.com/vector-im/riot-web/pull/9957
The two hacks introduced here are for different reasons, mostly related to the welcome page. If you land directly on the welcome page, the app's lifecycle is highly unlikely to have a bootstrapped client. This results in the loggedIn class being false. When the client is later set up (loaded from session, new guest account registered, etc) the context fails to update for the EmbeddedPage, and we need to give it a kick to re-render. It's arguable if we should even keep using the context here.
The RoomTile gets remounted during logout due to the room stores being obliterated, however this causes the render() function to check if it should be showing custom status. If you have custom status enabled, and the person has a status set, the function errors due to no MatrixClient being available.
Fixes https://github.com/vector-im/riot-web/issues/9940
This changes read receipt sending logic to allow it advance further into events
without tiles (such as edits or reactions) that may exist after the last
displayed event.
By allowing the read receipt to advance past such events, this also marks as
read any related notifications. For example, edits trigger notifications by
default since they are `m.room.message` events, and with this change, such edit
notifications can finally be marked read.
Part of https://github.com/vector-im/riot-web/issues/9745
If the debugging mode of showing hidden events in the timeline is enabled, we
should also show replacements using the same view source tile as we do for
reactions. This allows easy debugging of replacement event data and also makes
the edit event look visually distinct from regular messages.
Fixes https://github.com/vector-im/riot-web/issues/9937
This adds additional receipt storage to so that we can handle cases where the
receipts and events lists get out of sync. If we ever find a user who previously
had a receipt but momentarily no longer does, we recover their previous receipt
and go with that until we hear something new.
Part of https://github.com/vector-im/riot-web/issues/9745
This changes how we determine read receipts for the entire message panel. We now
calculate read receipts for all events up front, which makes it easier to handle
hidden events by moving their read receipts up to the last shown event for
display purposes.
Part of https://github.com/vector-im/riot-web/issues/9745
Smooth scrolling browsers (Firefox) use the relative area to determine how much scroll to apply. Because breadcrumbs are short vertically, the scroll amount is minimal (3 units) in the Y direction. On browsers which don't smooth scroll the units are usually much higher (100 in Chrome on Win 10). Users seem to expect the scrolling to be quicker due to the horizontal space on breadcrumbs, so we add a bit more power to their scroll when it looks small.
Fixes https://github.com/vector-im/riot-web/issues/9394
Issue described in https://github.com/vector-im/riot-web/issues/9690.
With certain `window.devicePixelRatio` values
(e.g. `1.5789473684210527`), the calculated thumb width/height
would be a non-integer value.
Passing such values to `client.mxcUrlToHttp()` causes it to
generate URLs to the thumbnail API with non-integer values.
As per the spec, non-integer values are forbidden for that API and a
400 HTTP response is returned (`Query parameter b'width' must be an
integer`).
Fixing matrix-js-sdk's `mxcUrlToHttp()` to sanitize such values
would also be a good idea and likely fix more than just matrix-react-sdk
and riot-web. Still, it feels like matrix-react-sdk should play nice
as well, and not request thumbnails for weird widths/heights.
Signed-off-by: Slavi Pantaleev <slavi@devture.com>
The short time is still read out (eg: 15:24), however by ignoring the anchor we prevent the reader from saying the title of the containing span. This prevents readers saying "Wed May 22, 2019 at 15:24 15:24".
See https://github.com/vector-im/riot-web/issues/9747
