This regression was probably introduced in
4f4441fb07 and is caused by the fact that
the variable `isHtml` conflates two different meanings:
- The event contains an HTML message
- The event message is displayed using HTML
This is an important difference. Plain text messages that contain
emojies are rendered with an HTML string and thus have to be sanitized
etc. But they must not use the MarkDown CSS styles for HTML messages.
The MarkDown CSS styles include `whitespace: normal` because HTML events
use `<br/>`-tags for line breaks. Plain text messages with emojies
obviously don't use `<br/>`-tags, so these styles must not be applied.
Signed-off-by: Jonas Schürmann <jonasschuermann@aol.de>
We were still running the emojione regex on all messages to
determine if they were *only* emoji (for the big emoji). This is
pointless on messages that we already know don't have emoji.
Also stop exporting unicodeToImage because it isn't used anywhere.
Emojione has graphics for a lot of the symbol / dingbat characters
which are within the basic multilingual plane, but the new
fast-path regex was only detecthing surrogate pairs, so not
counting the symbols as emoji.
Adding the code code button was done by manipulating the HTML of
the event body to add a span tag, then adding the onclick handler
after the thing was mounted. Apart from splitting the code between
two places, adding the span tag was, according to Chrome's
profiler, taking up quite a lot of CPU cycles (apparently as soon
as you set the innerHTML on a div). Instead, just build the whole
lot together after the component mounts.
Trivial fast-path optimisation: plain text messages cannot possibly contain pre
blocks so there's no point in trying to parse them in order to add code copy
buttons.
Emojione's regex for detecting emoji is *enourmous* and we were
running it on every display name, room name, message etc every time
those components mounted. Add a much simpler regex to rule out the
majority of strings that contain no emoji and fast-path them.
Makes room switching about 10% faster (in my tests with all the
profiling turned on).
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>.
When there are no styled blocks or inline styles applied within blocks, just send text instead of HTML.
Also, don't add <br /> for the last <p> (the last block).
Fixes https://github.com/vector-im/riot-web/issues/3147
This is required to be able to specify the highlight language in fenced
blocks like the following:
```python
print("foo")
```
Signed-off-by: Johannes Löthberg <johannes@kyriasis.com>
This makes the following changes:
- Improve CountryDropdown by allowing all countries to be displayed at once and using PNGs for performance (trading of quality - the pngs are scaled down from 32px to 25px)
- "I want to sign in with" dropdown to select login method
- MXID login field that suffixes HS domain (whether custom or matrix.org) and prefixes "@"
- Email field which is secretly the same as the username field but with a different placeholder
- No more login flickering when changing ServerConfig (!) fixes https://github.com/vector-im/riot-web/issues/1517
This implements most of the design in https://github.com/vector-im/riot-web/issues/3524 but neglects the phone number login:
This will be updated in another PR to implement desired things:
- Country code visible once a country has been selected (propbably but as a prefix to the phone number input box.
- Use square flags
- Move CountryDropdown above phone input and make it show the full country name when not expanded
- Auto-select country based on IP
* WIP msisdn sign in
* A mostly working country picker
* Fix bug where you'dbe logged out after registering
Stop the guest sync, otherwise it gets 401ed for using a guest
access token for a non-guest, causing us to beliebe we've been
logged out.
* Use InteractiveAuth component for registration
* Fix tests
* Remove old signup code
* Signup -> Login
Now that Signup contains no code whatsoever related to signing up,
rename it to Login. Get rid of the Signup class.
* Stray newline
* Fix more merge failing
* Get phone country & number to the right place
* More-or-less working msisdn auth component
* Send the bind_msisdn param on registration
* Refinements to country dropdown
Rendering the whole lot when the component was rendered just makes
the page load really slow, so just show 2 at a time and rely on
type-to-search.
Make type-to-search always display an exact iso2 match first
* Propagate initial inputs to the phone input
* Support msisdn login
* semicolon
* Fix PropTypes
* Oops, use the 1qst element of the array
Not the array of object keys which has no particular order
* Make dropdown/countrydropdown controlled
* Unused line
* Add note on DOM layout
* onOptionChange is required
* More docs
* Add missing propTypes
* Don't resume promise on error
* Use React.Children to manipulate children
* Make catch less weird
* Fix null dereference
Assuming [0] of an empty list == undefined doesn't work if you're
then taking a property of it.
This has the benefit of not needing a spec for custom CSS. Instead we rigourously sanitise the values for custom data attributes that are transformed to CSS equivalents. `data-mx-color` translates to CSS `color` for example.
Instead of dropping the style attribute on `<font>` tags entirely, sanitise aggressively and only keep `background-color` and `color` keys, and also sanitise the values to prevent `url(XXXXXX)` and `expression(XXXXXX)` type XSS attacks.
Move the very minimal logic of highlightDOM into TextualBody
because then we can avoid scheduling a lot of timeouts which
would ultimately do nothing (ie. any messages that don't have code
blocks).
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.
