This repairs access to the "Quote" option of the message context menu by passing
down a getter so that we always access the most recent tile and reply thread
instances. This ensures the context menu uses the newest information about the
current event when determining menu options to show.
Fixes https://github.com/vector-im/riot-web/issues/9639
This displays the existing reactions a message has from all users below the
message.
Since we don't currently have an API to actually get these events yet,
adds a temporary hook that looks for a specific message to inject some sample
data. This helps build out the UI for now and can be removed once it exists.
Fixes https://github.com/vector-im/riot-web/issues/9573
This adds a new action bar component to hold multiple per-message actions. This
existing options button has moved to this new component, and is currently the
only action.
This naming is clearer as it doesn't really edit at all (it shows a context
menu). This should also be less confusing with actual editing when it arrives.
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.
Fixes https://github.com/vector-im/riot-web/issues/7997
This isn't super elegant, but it also provides some amount of utility for people. As users might leave the old room, it might be useful to see when exactly a room was upgraded. We should fix the underlying cause for infinite back pagination though.
Hopefully makes the syntax a bit nicer. Also uses ES6 async import
rather than require.ensure which is now deprecated. Also also
displays an error if the component fails to load rather than falling
over in a heap, which is nice.
I haven't found anyone who can justify to me why we need
more complicated plurals for i18n (even in Polish) for
%(senderName)s added %(addedAddresses)s and removed %(removedAddresses)s as addresses for this room.
Turns out the z-index was to make the avatar appear above the
EventTile_line even though it comes before in the DOM (it's
absolutely positioned to overlap with it). Instead, just put
it afterwards in the DOM.
Implement a UI to expose a JS-SDK API for cancelling and resending
a room key request for an event.
This is useful in scenarios where the user has dismissed the request
on their other devices and would like to send the restart the
verification dance manually.
Depends on JS-SDK PR https://github.com/matrix-org/matrix-js-sdk/pull/624
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. :(
