Opened 7 years ago

Closed 7 years ago

#4117 closed defect (fixed)

Text between "<" and ">" not shown in private messages on website

Reported by: Kurt Krampmeier Owned by: rails-dev@…
Priority: major Milestone:
Component: website Version:
Keywords: Cc:

Description

When using the function to write messages to other users (e. g. <http://www.openstreetmap.org/message/new/Kurt%20Krampmeier>), the system does not show text entered between "<" and ">" when displaying the message on the website. The brackets are not displayed also.

Adding such brackets around URIs is good practice to prevent wrapping inside and to allow reliable automated extraction of the URI. See <http://tools.ietf.org/html/rfc3986#appendix-C>

This bug can cause a lot of confusion to the reader, because relevant information can become hidden. If I had used the first sentence of this bug report in a private messeage it would read like this

"When using the function to write messages to other users (e. g. ), ..."

Change History (5)

comment:1 Changed 7 years ago by Tom Hughes

Resolution: wontfix
Status: newclosed

Because we allow HTML in message bodies there probably isn't much we can do about this as such text will look like an HTML tag.

The RFC you reference is providing recommendations for marking URLs in plain text, but our messages are HTML not plain text so if you really want to delimit URLs an <a> tag would be the appropriate way to do it.

Basically we should have chosen a non-HTML markup language for messages, diary entries etc, but we're didn't and now we're stuck with a sub-optimal but not really fixable situation.

comment:2 Changed 7 years ago by Kurt Krampmeier

Resolution: wontfix
Status: closedreopened

Wow, allowing HTML is so wrong. While you seem to have a quite good job in filtering dangerous parts, really fixing this behavior still should be reconsidered, since the messages are also sent as plain text mails and you can also answer these messages through email. Nobody would use HTML markup in plaintext mails

I also would not have figured out, that you can use some (undocumented?) HTML subset in the web interface. I guess, the majority of the users (who could write HTML) do not either. I expected this problem to be caused by incorrectly stripping HTML content instead of encoding dangerous characters.

While it might break some single older messages and blog posts, HTML support still should be removed. It think it causes much much more harm than good. Breaking of old messages could even be completely avoided by keeping the current behaviour for old messages and using a sane behaviour for future messages.

Is there really no chance to get this fixed?

comment:3 Changed 7 years ago by Tom Hughes

The HTML wasn't my idea, it's something I inherited,

You're right that it is a particular problem in the case of messages because they are also sent as plain text in an email.

Patches of course are welcome, but this is not something that is likely to reach the top of my priority list any time soon.

comment:4 Changed 7 years ago by Kurt Krampmeier

I wonder, what would happen, if you would simply disallow HTML in messages completely. Probably nobody would care much. See, the two other issues you just fixed (#4118, #4119 - thanks!) likely have affected a lot more users and perhaps more than half of all mails were broken. But still nobody considered these problems as significant enough, to file a bug report until I did it today.

Now just make a guess: How many users will open older mails, stored in their accounts before the change? These numbers will cease fast. How many of these mails will contain HTML intentionally, which could look broken more or less after the change? Probably not even 1%. How many will look right for the first time, because they contain some HTML syntax unintentionally? Maybe more than the ones, that get broken. How many mails will be broken so badly, that the cannot be read anymore? Probably none, since at least nothing would be hidden. The worst case would be some excessive markup, that gets displayed in the web interface. It is already displayed that way in the emails. Nobody cared about that ...

What would be the benefit? New Messages will also look right as emails. Nothing will be accidentally lost between braces. The risk of XSS and/or spoofing due to incomplete filtering of dangerous HTML parts is removed.

I simply do not see any relevant point for keeping the current behavior.

comment:5 Changed 7 years ago by Tom Hughes

Resolution: fixed
Status: reopenedclosed

New messages now use Markdown formatting which should fix this issue.

Note: See TracTickets for help on using tickets.