Fixes https://github.com/vector-im/riot-web/issues/8503
componentDidUpdate is called a lot, and we don't really want to keep checking the messagePanel, so this introduces a new flag to check if the init is even needed.
The fallthrough for `notifier_enabled` caused a NPE on `payload.error`, so this moves the fallthrough to where it is intended and sanity checks `payload.error` for next time.
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.
This lessens the warning for unstable-but-not-official versions while still communicating that the version is unstable. In the future, we may want to make this state dismissable.
Fixes https://github.com/vector-im/riot-web/issues/6435
This is done through an on-the-fly inverter for the settings. All the settings changed are boolean values, so this should be more than safe to just let happen throughout the SettingsStore. Typically a change like this would be done in the individual handlers (similar to how setting names are remapped to different properties or even different storage locations on the fly), however doing that for this many settings would be a huge nightmare and involve changing *all* the layers. By putting a global "invert this" flag on the setting, we can get away with doing the inversion as the last possible step during a read (or write).
To speed up calculations of the default values, we cache all the inverted values into a lookup table similar to how we represent the defaults already. Without this, the DefaultHandler would need to iterate the setting list and invert the values, slowing things down over time. We invert the value up front so we can keep the generic inversion logic without checking the level ahead of time. It is fully intended that a default value represents the new setting name, not the legacy name.
This commit also includes a debugger for settings because it was hard to visualize what the SettingsStore was doing during development. Some added information is included as it may be helpful for when someone has a problem with their settings and we need to debug it. Typically the debugger would be run in conjunction with `mxSendRageshake`: `mxSettingsStore.debugSetting('showJoinLeaves') && mxSendRageshake('Debugging showJoinLeaves setting')`.
This component displays login and register buttons. It's currently used in the
composer when viewing a room as a guest.
The name is confusing because the login flow uses are very similarly named
`mx_Login_box` as a wrapping around forms, which is totally different than these
buttons.
Additionally, the components is moved to `views/auth` since it is very simple
and auth related.
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.
* Put a cancel button on the first page of the create key backup
dialog
* Move settings logic into the room reminder: I know this is moving
logic *into* a view but RoomView is quite heavyweight as it is.
* Give the recovery reminder an explicit 'onDontAskAgainSet' rather
than onFinished which was getting called with false when the last
screen of the dialog was closed with the cancel 'x' rather than
the 'close' button.
https://github.com/vector-im/riot-web/issues/8066
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.
This adds an in-room reminder above the message timeline to set up Secure
Message Recovery so that your keys will be backed up. If you try to ignore it,
an additional dialog is shown to confirm.
Fixesvector-im/riot-web#7783.
Signed-off-by: J. Ryan Stinnett <jryans@gmail.com>
make mx_fadable not do anything anymore, and make room settings
full size.
Room settings haven't been designed yet, so all of this will
have a full pass when we have a go at it.
This ends up being translated to ?server_name= in the matrix-js-sdk, although that has a bug at the time of writing. It converts `server_name: ['a', 'b']` to `?server_name=a,b` instead of `?server_name=a&server_name=b`
For reference: the `viaServers` option is routed through the 'join_room' action to RoomViewStore#_joinRoom which is passed directly to the js-sdk http-api#joinRoom function.
Next steps:
* Fix the js-sdk parsing
* Make the SDK generate matrix.to links with ?via=
_loadMembersIfJoined is called from
_onRoomLoaded < _onRoomViewStoreUpdate, before incoming state
from the store is applied to this.state, so looking up the room
with this.state.roomId doesn't always work, which would cause
the members not to be loaded. Pass in the room instead.
This is more reliable with LL enabled as the syncing user is
only known when it was active in the current timeline
or when the members have been loaded
when peeking, the members weren't being loaded at all because
the room wasn't available yet,
and the need for loading the members was never re-evaluated after that.
This only loads the members once the user has joined the room,
which also helps to avoid load all the members before an invite
is accepted.
checkIfAlone() filters the whole member list, which is fine until
we do it once for every membership event, then we have an n^2
problem. Move it into the rate limited function.
Fixes https://github.com/vector-im/riot-web/issues/7163
stopPeeking is currently not called when navigating to a joined room
after having peeked a room. This causes the /events endpoint for the
peeked room to be called until peeking another room, even when not
viewing the peeked room anymore.
The current code would only stop peeking if you joining were true (note the nesting),
e.g. when waiting for your join to be confirmed by /sync.
This change might make stopPeeking called also when not needed by there is a guard in
that method to do nothing if not currently peeking.
* Show a spinner while we wait for widgets to be deleted
* Hide widgets while they're pending deletion
* Don't put another jitsi widget into the room if there's already
one pending
- implement generic dispatch to close user/room/group settings
- use dispatch to allow clicks on disabled left/right/middle panel to
close settings
A much more maintainable approach would be to use dedicate routing
instead of doing different things depending on what page of the app is
currently being viewed. At the very least we could make the concept of a
settings page generic.
Whilst testing various DM paths, @lukebarnard1 found that there were
many failures to add the room as a DM against the correct user. It
turned out most of the failures seen were because the user chosen
was the current user. If the user accepted an invite it would often
be marked as with themselves because we chose the sender of the
join event as the DM user.
This fix makes the DM room setting process the same for both the
inviting client and the invited client. A RoomState.members
event causes the DM room state to be set in the room, regardless
of whether we are currently `joining` (see previous impl.)
The two cases for setting a DM are:
- this user accepting an invite with is_direct
- this user inviting someone with is_direct
This should handle all cases for setting DM state.
Don't pop up the dialog as soon as we can't send a message.
Also removes dispatches used to keep the RoomStatusBar up to date.
We can get the same events straight from the js-sdk via the
pending events event.
Known issues at this point:
* The room-level setting accepts the current user's default, which is wrong
* The checkboxes on RoomSettings are not independent
* The checkboxes in RoomSettings need some layout fixes
Signed-off-by: Travis Ralston <travpc@gmail.com>
After accepting a 3pid invite.
Rather than clear the joining flag when the join request completes,
leave it so the RoomView can see that we're expecting the user to
be joined in the various stages that might go through (waiting for
join request, waiting for room object, waiting for 'joined' member
event). The problem in this case was that we had to wait a bit for
the last one, and there was no bit of state to represent it.
This hopefully also makes the logic somewhat simpler.
Fixes https://github.com/vector-im/riot-web/issues/5041
Ignore the update that comes in from the RoomViewStore when the
current room changes or we save our scoll state against the new
room rather than the old one.
Fixes https://github.com/vector-im/riot-web/issues/5010
onHaveRoom sets some more state (among other things) so putting it
in the setState callback so it could observe the new state caused
us to have to re-render again unnecessarily. Just give it the new
state as a parameter.
to keep the place we're scrolled to in rooms. This mainly eleimates
the extra, superfluous onRoomViewStoreUpdate callback that
happened when the previous room saved back its scroll state.
Moving the scroll state to a separate store means we can have this
not emit events because nothing needs to know when the scroll state
changes.
