https://github.com/matrix-org/matrix-react-sdk/pull/2826 checked
that we had data in the crypto store if the had credentials in
localStorage. However, SSO stores creds in localStorage and then
redirects the browser to remove the loginToken parameter from the
URL without starting crypto, so after the redirect, we see creds
in localStorage but no crypto data, and error.
Fix by marking when we've successfully initialised crypto and only
erroring if that flag is set.
Fixes https://github.com/vector-im/riot-web/issues/9695
so we can have fallback content in the regular content for clients
that don't support edits. Note that we're not reading m.new_content
yet as it's going to be a bit of a headache to change this.
So for now just sending the edit in both the normal content and
the m.new_content subfield, so all events out there already
are well-formed
Regressed in https://github.com/matrix-org/matrix-react-sdk/pull/2768
where we check for an existing stored account first and restore that
instead if it exist, telling the user. We usually make a guest account
when the user first hits the page though, so this just restored this
guest account.
Don't restore the account if it's just a guest account (which, as per
comment, is not perfect, but is definitely better than the current
behaviour).
Fixes https://github.com/vector-im/riot-web/issues/9581
We look to see if there's already a user logged in and if there is,
restore that session instead of logging the user in as their new
account. We still set this 'is_registered' flag though, even though
in that case it's not a newly registered account that's being restored,
so don't set in that case.
In the case of room upgrades, it is possible the client is trying to render the room create event, but the user has never been in the old room. This results in an error because the PermalinkCreator cannot possibly figure out a room ID.
Instead, we'll feed the creator an alternate room ID to try if the room object can't be provided.
Fixes https://github.com/vector-im/riot-web/issues/9636
When displaying a GIF, we always want to thumbnail so that we can properly
respect the user's GIF autoplay setting (which relies on thumbnailing to produce
the static preview image).
Fixes https://github.com/vector-im/riot-web/issues/9658
This changes to "did update" and also calls the reaction change handler to
ensure that we update the state of my reactions (to know which were sent by
you).
This simplifies `ReactionDimension` by using the emoji string everywhere instead
of keeping a separate text string as well. It should improve readability as
well, as the reaction events also have a field `key` which was the emoji
content, which was easy to confuse.
This makes it a bit easier to meet the requirements while still requiring a
fairly strong value. The progress bar displays a score of 3 as reaching 100% for
simplicity.
Fixes https://github.com/vector-im/riot-web/issues/9642
This repairs access to the "Quote" option of the message context menu by passing
down a getter so that we always access the most recent tile and reply thread
instances. This ensures the context menu uses the newest information about the
current event when determining menu options to show.
Fixes https://github.com/vector-im/riot-web/issues/9639
The configuration flag is intentionally long and annoying - the vast majority of people should not need this. The flag is intended to be used in development environments where accounts are often registered with no intention of them sticking around.
All `Room.timeline*` handlers must currently test for `room` first if they
expect it to exist. It is emitted not only for rooms, but also for timeline sets
without rooms, such as for notifications.
Almost all such handlers were correctly testing as needed, but it was missing
from `RoomBreadcrumbs`.
While that's quite confusing, we can start by testing for `room` when we expect
to have one.
Fixes https://github.com/vector-im/riot-web/issues/9630
This allows you to increment an existing reaction below a message by clicking on
it.
At the moment, this is not linked to the action bar, so they each are using
local state. We'll likely want to add some mechanism so that we can local echo
to both of these UI areas at the same time, but that can be done separately.
Fixes https://github.com/vector-im/riot-web/issues/9486
This displays the existing reactions a message has from all users below the
message.
Since we don't currently have an API to actually get these events yet,
adds a temporary hook that looks for a specific message to inject some sample
data. This helps build out the UI for now and can be removed once it exists.
Fixes https://github.com/vector-im/riot-web/issues/9573
Concludes https://github.com/vector-im/riot-web/issues/8593
We are no longer seeing this error being triggered, and are considering it fixed. As a result, the dialog can be removed to reduce the amount of dead code in the project.
This adds the primary reactions to the action bar. They act as toggles where you
can only select one from each group at a time.
Note that currently we aren't actually sending the reaction at all. That's left
for a separate task.
Fixes https://github.com/vector-im/riot-web/issues/9576
This removes the clickable inviter behaviour, as it was too confusing to reveal
the user info sidebar and also hide the invite. Keeping both on screen would be
okay, but seems a bit too complex to resolve right before RC.
In addition, this adds the full inviter MXID to ensure it's clear who invited
you.
This applies the new design for multiple buttons in the message action bar,
paving the way for more things to appear here.
In addition, this changes the existing options button to use the three vertical
dots icon. Some theme colors are also tweaked to align with what they were meant
to be from the unified palette.
This adds a new action bar component to hold multiple per-message actions. This
existing options button has moved to this new component, and is currently the
only action.
This naming is clearer as it doesn't really edit at all (it shows a context
menu). This should also be less confusing with actual editing when it arrives.
Now that we have a fancier password complexity check, remove the older minimum
length to avoid the feeling of two password style guides fighting each other.
This adds a password complexity rule during registration to require strong
passwords. This is based on the `zxcvbn` module that we already use for key
backup passphrases.
In addition, this also tweaks validation more generally to allow rules to be
async functions.
In addition to migrating password fields, this also removes the remaining
support for old-style validation in registration now that all checks have been
converted.
When submitting a form, we want to validate more strictly to check for empty
values that might be required. A separate mode is used since we want to ignore
this issue when visiting a field one by one to enter data.
As an example, we convert the pre-existing logic for the username requirement
using this new support.
Since we're keeping the input as a ref anyway, let's use that rather than
requiring the value to be passed to `validate`. This allows others to call
`validate` as well.
Travis Ralston