E.g. "Bob added a Acme widget", "Susan removed a Giraffe widget"
The name is calculated by taking the `name` in the event content, falling back on the `type`, falling back on the previous content `type`. This is then capitalised.
Previously, we were special-casing outgoing messages such that they were shown
as encrypted even when encryption had failed for some reason.
There's no need for this: outgoing messages have a working isEncrypted() method
which we can use to show whether the event has been encrypted yet. Arguably we
could do better than an open padlock for events in the 'encrypting' send state,
but I'm not really sure what.
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`
Fix for https://github.com/vector-im/riot-web/issues/4224
Due to the way `MatrixChat` does a state update when the `view_room` dispatch fires and a second update when `RoomViewStore` sends an update, the current event ID and room ID were becoming out of sync. The solution devised was to have the event ID managed by the `RoomViewStore` itself and do any defaulting there (for when we revisit a room that we saved scroll state for previously).
This required a few changes:
- The addition of `update_scroll_state` in `RoomViewStore` allows the `RoomView` to save scroll state for a room before swapping to another one. Previously the caching of scroll state was done in `RoomView`.
- The `view_room` dispatch now accepts an `event_id`, which dictates which event is supposed to be scrolled to in the `MessagePanel` when a new room is viewed. It also accepts `event_offset`, but currently, this isn't passed in by a dispatch in the app, but it is clobbered when loading the default position when an `event_id` isn't specified. Finally, `highlighted` was added to distinguish whether the initial event being scrolled to is also highlighted. This flag is also used by `viewRoom` in `MatrixChat` in order to decide whether to `notifyNewScreen` with the specified `event_id`.
Every file has now been manually vetted by me. Due to the extent of
the changes, I've been unable to test all scenarios to make sure this
all works. :(
- Shift to the left _before_ adding an avatar so that there are always `MAX_READ_AVATARS` visible, instead of there being `MAX_READ_AVATARS + 1` avatars displayed following the first "collapse".
- Use `right` instead of `left` so that double-digit remainders don't get overlapped.
Add Modal.createDialogAsync, which can be used to display asynchronously-loaded
React components. Also make EncryptedEventDialog use it as a handy
demonstration.
Fixes a bug introduced in
https://github.com/matrix-org/matrix-react-sdk/pull/426.
Particularly when we are showing search results, we may not recognise the
sender of an event; attempting to create a MemberAvatar for it will lead to
null-reference errors.
Also a bit of untangling of the logic of needsSenderProfile. Since
https://github.com/matrix-org/matrix-react-sdk/pull/422,
EventTileType.needsSenderProfile was only being called on MessageEvents, and
therefore only returned true. It's a shame to see all this logic going into
EventTile rather than the individual EventTileTypes, but since it's there,
let's not leave the unused logic lying around in the EventTileType
implementations.
This is the react-sdk part of
https://github.com/matrix-org/matrix-js-sdk/pull/146. It adds 'Block'/'Unblock'
buttons to the device list, and updates the deviceVerified listeners to listen
for deviceVerificationChanged instead.
Also adds an extra <div> to the deviceinfo section to help me with the
CSS.
... hopefully fixing https://github.com/vector-im/vector-web/issues/1437 in the
process.
The idea here is that, when we remove a read-receipt from the DOM, we stash its
position in a map. Then, when the read-receipt appears again attached to
another event, we know where to start the transition.
Each individual eventtile isn't particularly expensive, but when you have 500
of them, they start adding up. Shuffle some of the stuff into MessagePanel, so
that we can shouldComponentUpdate EventTiles properly.
Switch to using a normal <a href="..."> link for search result
clickthrough. Apart from generally giving a better experience, this means that
it also works on html messages. The problem there was that we were attaching
onClick handlers to <span>s which we were then flattening into HTML with
ReactDOMServer (which meant the onClick handlers were never attached to React's
list of listeners).
To make this work without jumping through React hoops, the highlighter now
returns either a list of strings or a list of nodes, depending on whether we
are dealing with an HTML event or a text one. We therefore have a separate
HtmlHighlighter and TextHighlighter.
