This adds a link to the login screen with "Forgot your password?". Clicking it
takes you to a form with fields for an email address and a new password. This
makes the same API calls as the Angular SDK.
Manually tested resetting + not clicking link + invalid email and it all seems
to work.
When we first get video, the video component will resize itself. This will
cause the page to be reflowed, but that doesn't trigger an update on the gemini
scrollbar. We therefore need to force an update on the messagepanel. Implement
this by providing an onResize property on the CallView component.
We need to do the same when we change the maxHeight on the video panel.
The same applies to resizing of the MessageComposer. That was previously
handled with a fugly roomView.forceUpdate() from MessageComposer - make it use
the same mechanism.
Finally: the messageComposer is at least 70 pixels, and up to 100 pixels high -
not 36. Fix the auxPanelMaxHeight calculation - and use a static constant
rather than hardcoding the number to avoid this happening again.
Make sure that we *actually* give preference to longer search result
highlights; it turns out that the code that looked like it was doing so has
never worked.
We need to return 'true' from our promise of search result pagination.
Also inline _backPaginateSearch which mostly served to confuse, and use
debuglog instead of checking DEBUG_SCROLL
Given we want to use isAtBottom to figure out whether to show 'unread messages'
counts, we ought to return the current scroll state, rather than the saved one.
This fixesvector-im/vector-web#576
The dance to avoid doing repeated fill requests on every update is common, so
add it to ScrollPanel. Let onFillRequest return a promise, which prevents any
updates until it completes.
- Make onBlur reset the EditText to show that it hasn't submitted it.
- Add the user ID of the logged in user to Advanced.
- Remove remnants of the Save/Cancel buttons.
- Swap Phases enum to be using string literals
- Swap roomId prop on UserSettings for a more sane onUserSettingsClose and
make MatrixChat responsible for swapping the room.
- s/then/done/ when terminating Promise chains to avoid subtle errors.
- Rejig render() of UserSettings so we don't need to indent quite so much.
This is required for automatically entering tab-complete mode because
onKeyDown is NOT called in that case, so we need to make sure to have a
membership list hanging around.
RoomView is the parent component which creates MessageComposer AND the status
bar. By making RoomView instantiate TabComplete we can scope instances
correctly rather than relying on singleton behaviour through dispatches. This
also makes communication between status bar and the MessageComposer infinitely
easier since they are now sharing the same TabComplete object.
Refactor the event-tile generation loop to go forwards rather than backwards,
which makes it easier to figure out whether we are displaying a continuation of
the previous event, and whether we need a date separator.
Also only display the date separator at the top of the room if there's no more
scrollback to be shown.
This fixesvector-im/vector-web#431
* factor out the call to MatrixClient.search to a separate _getSearchBatch (so
that we can reuse it for paginated results in a bit)
* Don't group cross-room searches by room - just display them in timeline
order.
This is preferable to doing the way other QPs are passed (secret, etc) because
the link in the email wants to look like "#/room/<room_id_or_alias>" for guest
read-access (only bouncing you to /login if that room is not readable by guests).
This is hard to do in the current arch because we don't preserve QPs on /room
paths, and we do conditional executions depending on if it is a room ID or
alias. Rather than threading through the email in each section and creating
a fragile mess, just pass the *starting* set of query parameters through to
MatrixChat which can then do the Right Thing when the time comes.
Remove an optimisation which tried to avoid recalculating the scroll on every
render. The problem is that sometimes, when new events, the number of event
tiles remains the same, but we still need to do a scroll, because the height of
the message list changes.
The optimisation was a bit of a waste of time anyway - the actual render will
always be much more difficult than recalculating the scroll position.
