Element-web: Clipped URLs don't resolve correctly

[devinrsmith]

When exploring public rooms, there is a description of the room. It seems that if that description has a URL, and the URL is clipped, the URL doesn't resolve correctly.

In the example above, clicking the link takes me to https://fedoraproje/. You can see in the full room description the proper URL.

I'm on OS X Element 1.7.5.

[michel-zimmer]

The problem is here: https://github.com/matrix-org/matrix-react-sdk/blob/c6834fd428f3118bee6be4cd5f78941f0939b2ba/src/components/structures/RoomDirectory.js#L500

The room topic is truncated first, then the link handling is applied and it detects https://docs.fedor as a valid link.

[t3chguy]

@michel-zimmer good spot, a PR would be very welcome :)

[michel-zimmer]

Thanks! I think, this one is not for me, unfortunately: I don't know of a way how to do this, that is not overly complicated (read: entirely hand made and error prone and hard to maintain). :man_shrugging:

[t3chguy]

I think the easiest way would be having CSS do the trimming, maybe keeping a 5x limit in JS. So truncate to 500 in JS, then clip to max 3 lines in CSS or something

(clipping in JS is just to protect against insanely long topics bogging down the DOM)

[michel-zimmer]

Oh, yes, you are right. Didn't think outside of the box hard enough and though something along the lines: If I do it with CSS, then I don't know if it becomes problematic, if the topic is still very long underneath. :man_facepalming: But yes, JS and CSS together should do this, of course.

As long as nobody starts working on this I'll give it a shot in the next days.

[t3chguy]

See https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-line-clamp

[michel-zimmer]

See https://developer.mozilla.org/en-US/docs/Web/CSS/-webkit-line-clamp

Thanks :+1:

Okay, now you've got me thinking: How perfect should the solution be?

If it's a very long link at the end of the topic then the same problem still applies. The topic length is 160 characters now. That would be 800 characters if we use the arbitrary multiplier of 5. So if we have a link starting maybe at around character 150 that is 650+ characters long we might run into the same problem.

I actually think this is totally reasonable and times 5 respectively 800 characters should work quite well (because why would anyone need such long links in a topic description…), but I wanted to bring this up once, so that we have a record for this decision.

[t3chguy]

If someone wants to put a 100+ character link in a topic then that's their fault for not using a URL shortener, shame on them :')

I don't expect the solution to be perfect, but achieve these two goals

• Perform a consistent (to the line number) truncation on the topics, rather than arbitrarily long in number of characters
• Let links work in more typical conditions which were previously wrongly cut off.

[michel-zimmer]

The CSS truncation is in regards to lines, not to characters. In general I would go with 3 lines. But I'm wondering if there is a system for break-points in place, like for example when the room bar on the left collapses on small screens. Because in that case 4 lines would work a bit better - just like how it's the case right now with JS / character truncation only.

[t3chguy]

Css is capable of being conditional on screen resolution, but in the case of the room directory which is a modal, the size doesn't vary much

[michel-zimmer]

I know :wink: I was wondering if there are already reusable media queries in the code base.

If it becomes smaller it looks like this (3 line clamp):

So maybe it makes sense to increase it to 4 lines for small screens like this:

In some cases this might actually help, but I don't care that much and you've already stated

Perform a consistent (to the line number) truncation

above, so I will always just use 3 lines and if it becomes a problem for someone, then they should open a new issue.

[t3chguy]

I'd say 3/4 lines is sane, then the further down the line issue could be the ability to see the full topic regardless of truncation on user demand