It turns out that the assertion made in
https://github.com/matrix-org/matrix-react-sdk/pull/1213 about `async`
functions returning bluebird promises was only correct when babel used an
inline version of the `asyncToGenerator` helper; in react-sdk we are using
`babel-transform-runtime` which means that we use a separate
`babel-runtime/helpers/asyncToGenerator`, which returns a native (or core-js)
Promise.
This meant that we were still in the situation where some methods returned
native Promises, and some bluebird ones, which is exactly the situation I
wanted to resolve by switching to bluebird in the first place: in short,
unless/until we get rid of all code which assumes Promises have a `done` method
etc, we need to make sure that everything returns a bluebird promise.
(Aside: there was debate over whether in the long term we should be trying to
wean ourselves off bluebird promises by assuming all promises are native. The
conclusion was that the complexity hit involved in doing so outweighed any
benefit of a potential future migration away from bluebird).
Use bluebird instead of the now removed "q" library.
Also, make sure we timeout and then `reflect` to effectively do an `allSettled` that waits for all promises to either be resolved or rejected. Then we filter for those that are fulfilled and return the completions.
The easiest way to stop the user from inserting whitespace onto the end of an entity is to toggle the entity state of the whitespace that was just entered. This allows the user to continue drafting a message without editing the link content.
This is for pasted `<a>` tags that have been copied from a website. We probably also want to be storing entities for substrings of content that are determined to be URLs.
This was used by the old composer to control whether to interpret text as markdown prior to sending.
The new setting is `MessageComposerInput.isRichTextEnabled`.
We recently updated our version of emojione but this update included the addition of emoji represented in unicode with ZWJ (Zero-Width-Joiners). These ZWJs are not present in the asset file names, so any emoji with ZWJ in them were just not found (404 on the web client).
This updates `unicodeToImage` to be compatible with emojione 2.2.7 so that the correct filenames are used when converting from unicode to <img>.
Sometimes it was possible for there to be a scroll event before the initial
pagination completed, which then upset the rest of the test. Just give it a few
ms to sort itself out instead.
