As detailed here https://docs.google.com/document/d/1UWqdS-e1sdwkLDUY0wA4gZyIkRp-ekjsLZ8k6g_Zvso/edit, the RM state is no longer kept locally, but rather server-side. The client now uses it's locally-calculated RM to update the server and receives server updates via the per-room account data.
The sending of the RR has been bundled in to reduce traffic when sending both. In effect, whenever a RR is sent the RM is sent with it but using the new API.
This uses a js-sdk change which has set to be finalised and so might change.
apparently when we added the buttons to export e2e keys to the Logout button, we didn't change the text warning the user that e2e export was coming soon. likewise when changing password and forgetting password (where we didn't even have a button to export keys)
This was an issue because guests do not log in with a teamToken, it is implicitly set by MatrixChat when it mounts. The fix is to view_home_page when a login occurs and MatrixChat has this._teamToken set.
- Create a promise that will serve as a lock to be blocked on by things that need to wait for the first sync before accessing state.
- Use this promise to block `view_room` calls until a sync has occured instead of just dropping them silently if the sync hasn't happened yet.
- Store the current room ID in a localStorage item `mx_last_room_id` when `view_room` fires. This persists the last viewed room ID so that it can be restored on refresh, browser quit. This replaces the previous logic which set the room following a sync based on the most recent unread room.
Making sure that a node is intersected by the bottom of the wrapper is a bit overkill, given that we iterate from the bottom. This also prevents the scenario of having no nodes that are not precisely intersected, but possibly straddling the bottom of the wrapper.
Also get rid of the "up" arrow so as not to indiciate direction. This is important because in future the RM will not be based on what has been paginated into the client (but instead RM will be handled server-side) and thus we cannot assert any kind of direction on it relative to the events in the viewport.
