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')`.
If we can't start indexeddb, fall back to a different store.
Previously we just ignored the exception and ploughed on anyway, on
the assumption that startup() was just for the indexeddb store to
load data anyway, and if that failed it would just do an initial
/sync instead (and also we'd keep trying to save the sync back which
would fail...). Then, in the previous release we started pulling
the settings out of the store on startup, making the assumpton that
the store actually worked, so the read obviously failed and the app
failed to start up.
This makes Riot work in Tor browser / firefox in daft mode again.
As we need an option to turn lazy loading on (we can't just accept a filter,
as /messages has an incompatible filter), better only pass the option
and create the filter inside startClient
For setting:
- name
- topic
- history visibility
- power levels
Testing RoomSettings required more stubbing on the matrix client.
The power level tests should be failing at this commit, with
fixes being made in upcoming commits.
Some tests are marked as known failures that we should fix but
aren't necessarily bugs:
- SettingStore.setValue is used when saving despite the user not
having made a change.
- Testing directory publicity changes cannot be tested because we
update state asynchronously in componentWillMount (which we do
not block on in beforeEach).
Also, we needed to use `export default` to make sure everything
uses the same client peg and client.
The feature is incredibly buggy and doesn't work as expected due to server behaviour and client interaction. One of the major problems is the constantly confused presence state - this is caused by the mobile apps conflicting on the state of the web app, causing it to consider the user offline or online (and rarely away) depending on how riot-android/ios is behaving at the time.
This reverts two PRs:
* https://github.com/matrix-org/matrix-react-sdk/pull/1620
* https://github.com/matrix-org/matrix-react-sdk/pull/1482
The changes to the context menu positioning were not reverted as they are useful outside of presence management.
Signed-off-by: Travis Ralston <travpc@gmail.com>
This introduces a generic way to register certain events emitted by
the js-sdk as those that should be propagated through as dispatched
actions.
This allows the store to treat the js-sdk as the "Server" in the
Flux data flow model. It also allows for stores to not be aware
specifically of the matrix client if they are only reading from it.
Includes rudimentary support for custom statuses and user-controlled status. Some minor tweaks have also been made to better control how we advertise our presence.
Signed-off-by: Travis Ralston <travpc@gmail.com>
the js-sdk is making some of its APIs asynchronous, and adding an `initCrypto`
method which you have to call.
Particular methods we need to worry about are:
* `getStoredDevice`
* `getStoredDevicesForUser`
* `getEventSenderDeviceInfo`
* `isEventSenderVerified`
It turns out that Firefox doesn't let you use indexeddb from private tabs,
*unless* you are *also* in a webworker. We need to either consistently use it
or not use it - so let's use it.
* don't just log errors without any context as to where they came from or what
they mean
* avoid the use of '%s' and multi-argument console.log because it looks awful
under karma.
Get rid of MatrixClientPeg.replaceUsingUrls, and instead create local,
temporary MatrixClients for the unauthed steps; we therefore only use
MatrixClientPeg for logged-in clients.
Don't clear localstorage when replacing the client: we clear it when logging out so this is just redundant, and since we now use replaceClient to unpickle a session from localstorage, this was blowing away all our setting on every refresh.
Also Move all of the localstorage code to Lifecycle (except device ID but this will probably be generated on the server soon anyway). We previously cleared localstorage on logout in Lifecycle so persist the session in Lifecycle.setLoggedIn() to be symmetrical.
This means that we don't create a spurious MatrixClient which is thrown away by
the SessionLoader (whilst still ensuring that the rehydrated matrixclient
follows the same code path as matrixclients created at other points in the
session load process).
