-
-
Notifications
You must be signed in to change notification settings - Fork 831
Extend slash command '/topic' to display the room topic #2532
Conversation
If no <topic> is provided, the command will display a modal dialog containing the sanitized and linkified room topic. This is just adding some juice to make reading long room topics more convenient.
Signed-off-by: Bastian <[email protected]>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This generally looks excellent, thank you! We should sort out our linkification and sanitisation into one place as it doesn't really make sense to import linkifyMatrix
in here, but it's what we do elsewhere. We also seem to vary in our sanitisation of text, ie. in TextualBody we also escape()
the text before passing it to sanitizeHtml
but in other places we don't.
Also a I think a QuestionDialog with no cancel button probably gives you a dialog that can't be dismissed with the escape key which is not quite what you want, but again it's what we do elsewhere so for now it's better to be consistent.
The one thing I would say is what happens when the room has no topic?
ftr I've tracked our sanitisation / linkification issues in element-hq/element-web#8337 |
Signed-off-by: Bastian <[email protected]>
Display a default message if no room topic is present Signed-off-by: Bastian <[email protected]>
Signed-off-by: Bastian <[email protected]>
Add HtmlUtils.linkifyElement() Add HtmlUtils.linkifyAndSanitize() Refactor module imports Signed-off-by: Bastian <[email protected]>
Signed-off-by: Bastian <[email protected]>
Hi Dave,
I consolidated the linkification methods in HtmlUtils, but ignored escaping for the moment.
"QuestionDialog" was replaced by a new Modal "InfoDialog", as you suggested. For closing the InfoDialog using the Keyboard, press the [Enter] key.
In that case the Modal now shows a message: "There is no room topic." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for going the extra mile on this! Just a couple of fixes to your new stuff I'm afraid. (Also what I should have said is that it might be better to open a separate PR to add InfoDialog and bigger things like that, but let's carry on with this one: I think we're almost there).
@@ -438,7 +433,7 @@ module.exports = React.createClass({ | |||
if (topic.length > MAX_TOPIC_LENGTH) { | |||
topic = `${topic.substring(0, MAX_TOPIC_LENGTH)}...`; | |||
} | |||
topic = linkifyString(sanitizeHtml(topic)); | |||
topic = linkifyAndSanitizeHtml(topic); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So this was linkifyString(sanitizeHtml(..))
previously but linkifyAndSanitizeHtml()
does it the other way around: sanitizeHtml(linkifyString(...))
: I suspect this is probably fine but obviously if it's wrong it's a very big deal. Is there a reason to change it?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
For security reasons, the specified (insecure) string should always be sanitized last. F. e., someone could figure out how to do nasty things during linkification, thus bypassing the HTML sanitizer completely. Anyways, linkifyString() should always produce valid HTML that passes the sanitizer.
Of course, I could be on the wrong track here, so please feel free to correct me. :-)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good thought, although in practice linkifyString
happens to escape HTML as it's intended for parsing plaintext strings, so this will end up escaping all HTML attributes.
So Riot, by doing it the other way around, was also sanitising the HTML and then completely escaping it, meaning no HTML could actually be used, so you found a bug there.
In a further plot twist, the topic is not actually HTML at all: I don't know why RoomDirectory was using sanitizeHtml
and dangerouslySetInnerHTML
, since in RoomHeader, it's just escaped normally as a plain text string and linkified. However, because of the above bug, RoomDirectory was escaping the sanitised HTML and ended up being consistent with the room header...
Sorry you've unwittingly got tangled up in this mess: If we were to fix this, I would probably make a LinkifedText
component which takes the linkification out of https://github.com/matrix-org/matrix-react-sdk/blob/master/src/components/views/rooms/RoomHeader.js#L307 / https://github.com/matrix-org/matrix-react-sdk/blob/master/src/components/views/rooms/RoomHeader.js#L81 ie. using React's normal string escaping. and then pointing linkify at the DOM element.
That said, this PR has the same behaviour as before so we could also merge this and then fix it later: you've put more than enough work in to this PR!
One more thing: your parameter to linkifyAndSanitizeHtml
isn't used in either of the calls: I would remove it and always use our sanitisation options (it's also a bug in Riot that it was using sanitize-html's default rather than our own, but it didn't matter anyway because the HTML all got escaped anyway).
Signed-off-by: Bastian <[email protected]>
Signed-off-by: Bastian <[email protected]>
Signed-off-by: Bastian <[email protected]>
Signed-off-by: Bastian <[email protected]>
Hey Dave, thanks for the review! Ok, I will consider in the future and create own PR for such changes. I hope now everything is fine. |
Signed-off-by: Bastian <[email protected]>
Signed-off-by: Bastian <[email protected]>
If no topic is provided, the command will display a modal dialog containing the sanitized and linkified room topic. This is just adding some juice to make reading long room topics more convenient.
Signed-off-by: Bastian [email protected]