This reworks the API the `InteractiveTooltip` component so that it's more
natural to use just like other React components. You can now supply the target
component as a child and the tooltip content as a prop.
In addition, this tweaks the interactivity to keep the tooltip on screen until
you move the mouse away from the tooltip and its target.
Part of https://github.com/vector-im/riot-web/issues/9753
Part of https://github.com/vector-im/riot-web/issues/9716
This adjusts the positioning to work more the way we want:
* Tooltip is position on the top or bottom edge of the target depending on where
space is available
* Tooltip and chevron are centered
In addition, more bits borrowed from `ContextualMenu` are not needed, so they
have been removed for simplicity.
Part of https://github.com/vector-im/riot-web/issues/9753
Part of https://github.com/vector-im/riot-web/issues/9716
As part of reactions and editing work, we're adding a new style of tooltip that
allows interacting with the content of the tooltip. `ContextualMenu` is closest
out of the things we have today, but it doesn't position in quite the way we
want and it's already quite complex.
To get started, let's first clone that to a new `InteractiveTooltip`.
Part of https://github.com/vector-im/riot-web/issues/9753
Part of https://github.com/vector-im/riot-web/issues/9716
My brain can't deal with two different ways to write "Tooltip", so this
converges the naming to match the rest of the code base. Separate commits will
fix up the file names for case-insensitive file systems.
This moves the responsibility of creating a URL to open from the button (and other components) to the integrations manager dialog itself.
By doing this, we also cut down on scalar API calls because we don't pick up on account information until the user opens the dialog.
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
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.
This adjusts the submission step to focus the first invalid field and redisplay
validation. This also rearranges the older style field error handling on
registration which is slated for removal once we convert all fields to the new
style.
This updates the registration form to include the new-style validation state
when deciding whether the entire form is valid overall.
In addition, this tweaks the validation helper to take functions instead of
strings for translated text. This allows the validation helper to be create once
per component instead of once every render, which improves performance.
The `BottomLeftMenu` component is not used in the new design. This removes the
component and also any images and sub-components that were only used by it.
The class name handling for validation inadvertently added `undefined` as a
class when validation is not used. This rearranges the logic to avoid the issue.
Fixes https://github.com/vector-im/riot-web/issues/9345
Add i18n entries for rotating images; fix the way `getName` is defined
Signed-off-by: YaoiFangirl420 <48789208+YaoiFangirl420@users.noreply.github.com>
This ensures we always include the current power level in the power selector,
even if it's greater than the level you're allowed to set yourself. This ensures
the selector can display the current value correctly when disabled.
Fixes https://github.com/vector-im/riot-web/issues/9340
When setting, delete the old one. Because delete checks if it exists first, we can safely call this.
The change in FromWidgetPostMessageApi is just something noticed while debugging.
Having the referrer allows widgets to do customisation based on what
riot instance is embedding it. It gets a referrer when we embed it
in the iframe so there's nothing gained by suppressing it here.
Fixes https://github.com/vector-im/riot-web/issues/6437
This also fixes a bug where if the room had apps open and you clicked the sticker picker's title, you'd end up closing the apps and not the picker.
Fixes a bug for some widgets where they cannot do their startup routine (capabilities negotiation, etc) when someone maximizes the widget. By reloading the widget messaging, we ensure the widget is kept in the loop.
When working on the `Field` validation support, I thought `RegistrationForm`'s
refs would be okay to leave as is, but I missed that they also depended on the
value getter.
For the moment, it's quicker to temporarily revive the value getter to get
registration working.
Fixes https://github.com/vector-im/riot-web/issues/9171
Since Scalar (and other integration managers) are loaded as apps into
an iframe, a valid `scalar_token` must exist when loading the app.
It is possible that a scalar_token becomes invalid between the time
when the integration manager button was rendered and the user clicking
the link. Here we make a call to integration manager `/account`
before trying to render the integration manager, which ensures we
have a valid token for the integration manager to work with.
Moving the scalar token revalidation to the cases where it is actually
needed could make it possible to decrease the amount of Scalar /account
calls we do when switching rooms, which is currently 3.
Signed-off-by: Jason Robinson <jasonr@matrix.org>
As part of adding validation to Field, the logic is simpler to follow if we can
assume that all usages of Field use it as a controlled component, instead of
supporting both controlled and uncontrolled.
This converts the uncontrolled usages to controlled.
* renames RoomTooltip to be a generic Tooltip (which it is)
* hooks it into Field to show validation results
* adds onValidate to Field to let Field instances call an arbitrary validation function
Rebased from @ara4n's https://github.com/matrix-org/matrix-react-sdk/pull/2550
by @jryans. Subsequent commits revise and adapt this work.
This allows Fields to have an optional prefix component which is placed inside
the border of the Field and to the left of the input. Since this label animation
would be complex to get right for this case, it is instead fixed to the top left
if there is a prefix component.
This canonical example of this today would be a phone number field which
includes a country dropdown.
Several small tweaks to the props handling:
* Use destructuring instead of `delete`
* Emphasize the `element` as a primary prop
* Document `textarea` as supported
These icons are based on Feather as the original source, but they have various
tweaks applied, such as stroke width, color, etc. Hopefully the tweaked name
makes this more obvious in the future.
as not all state that goes into rendering comes from state or props,
we shouldn't be blocking rendering at all
This might rerender a few times more, but it shouldn't be worse
than what was there before the redesigned roomlist.
They do local echo on changes to avoid jumping back and forth while requests are ongoing, however some areas modify the checked state after the toggle has mounted.
Fixes https://github.com/vector-im/riot-web/issues/8432
This takes out the old user and room settings, replacing the paths with the new dialog editions. The labs setting has been removed in order to support this change.
In addition to removing the old components outright, some older components which were only used by the settings pages have been removed. The exception is the ColorSettings component as it has a high chance of sticking around in the future.
Styles that were shared by the settings components have been broken out to dedicated sections, making it easier to remove the old styles entirely.
Some stability testing of the app has been performed to ensure the app still works, however given the scope of this change there is a possibility of some broken functionality.
Fixes https://github.com/vector-im/riot-web/issues/8250
This keeps all fields in line with the design without them having to defining it twice. The option is kept in the first place as some fields might want to override the placeholder to be longer than the label or something.
Also bring in the compact timeline option.
Without minor CSS changes, the old user settings are completely unusable with this change. As such, minimal effort has been put in to have it be useful. Similarly, the changes drop the use of radio groups and the old theme selector was the only one that used it. See the comments for more details on how/why this was mitigated the way it was.
The label moves into the border on focus and after being filled. A valid color
is applied to the label and input border. Other states like invalid can be added
later as needed.
Adapted from @ara4n's experiment into a React component with a CSS only
approach.
This allows Webpack to insert the proper image URL after builds steps like
adding a hash and so on. The path you supply to `require` is relative to the JS
source file, just like any other would be.
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/5689
Some dialogs had their own CSS that prevented the buttons from being placed in the right spot. This has been fixed by using a generic standard for the buttons. The only strange dialog that needed more CSS was the devtools dialog due to the header.
Not all dialogs have been checked - I spot-checked about half of them and verified the CSS manually on an established account. It's hard to get at all the dialogs without convoluted testing.
With this more of the
controls that look like buttons can be operated via the keyboard and
navigated to by screen reader users. This includes editor buttons such
as File upload, Audio / Video call, Right pannel hide button, Jump to
the bottom timeline button, and some more buttons found in the user
settings.
Also I have added alt texts to some images that in turn label buttons
which these happen to be packed in and removed some untranslated alt
texts from decorative non-actionable images that might add more
verbosity when talking about screen reader user experience.
ActiveWidgetStore is now reponsible for removing the current
persistent widget from the store if it's been removed from whatever
room it was in. As per comment, this leaves us with the store updating
itself in this case but in all other cases, views call setters on the
store to update its state. We should make it so the store keeps itself
up to date and views aren't responsible for keeping the store up to date.
The store now emits events so it can notify PersistentApp when it changes.
Fixes https://github.com/vector-im/riot-web/issues/7076
As per https://github.com/matrix-org/matrix-doc/issues/1354
This is whitelisted to only jitsi widgets for now as per comment,
mostly because any widget that we may make always-on-screen we need
to preemptively put in a PersistedElement container, which is
unnecessary for any other widget.
Apologies that this does a bunch of refactoring which could have
been split out separately: I only discovered what needed to be
refactored in the process of doing this.
Fixes https://github.com/vector-im/riot-web/issues/6984
This reverts a fix to EditableText introduced in
https://github.com/matrix-org/matrix-react-sdk/pull/1445
which introduced a bug that causes room name and topic to
reset when UserSettings is rerendered because
`initialValue != this.value`
This also fixes the same bug originally fixed by #1445:
>fix entering the same thing twice (which had the bug of not
>emptying the "new" field)
which, in other words meant that clicking "+" when adding a room
alias would not reset the contents of the bottom-most alias in the
list.
The fix is to increment the `key` of the element, causing a new
instance to be mounted instead of passing new props to the existing
one.
Widgets would sometimes briefly re-appear after having been deleted.
This was because of the following race:
* User presses delete, send POST req, we set `deleting`. Widget hides.
* POST request completes, we unset `deleting` so widget unhides.
* State event comes down sync so widget hides again.
This fixes this by introducing `waitForRoomWidget` and using it to
wait until the state event comes down the sync until clearing the
`deleting` flag.
Since we now have `waitForRoomWidget`, this also uses it when adding
a widget so the 'widget saved' appears at the same time the widget
does.
