Legal/Markdown bug in Terms of Service


(Dan Fabulich) #1

In the first paragraph of the Terms of Service, there’s a bug in the Markdown, stripping out part of the legalese. Here’s the Markdown code Discourse Meta

The Website is offered subject to your acceptance without modification of all of the terms and conditions contained herein and all other operating rules, policies (including, without limitation, discourse.org’s [Privacy Policy](/privacy) and [Community Guidelines](/faq)) and procedures that may be published from time to time on this Site by CDCK (collectively, the "Agreement").

But here’s how that renders:

The Website is offered subject to your acceptance without modification of all of the terms and conditions contained herein and all other operating rules, policies (including, without limitation, discourse.org’s Privacy Policy and Community Guidelines) and procedures that may be published from time to time on this Site by CDCK (collectively, the “Agreement”).

The whole second half of the sentence (in particular the part that defines “Agreement”) has been stripped out, and the Privacy Policy link is broken, pointing to: https://meta.discourse.org/privacy)%20and%20[Community%20Guidelines](/faq))%20and%20procedures%20that%20may%20be%20published%20from%20time%20to%20time%20on%20this%20Site%20by%20CDCK%20(collectively,%20the.

It’s not clear to me whether this is a bug in the Markdown parser or the Markdown code of the TOS. You can workaround the bug by using the square-bracket syntax for links, like this: Privacy Policy[1]


(Dan Fabulich) #2

There’s also an annoying bug that the default ToS on a fresh forum uses “www.example.com” instead of discourse.org, and that this creates a broken hyperlink.

The Website is offered subject to your acceptance without modification of all of the terms and conditions contained herein and all other operating rules, policies (including, without limitation, www.example.com’s [Privacy Policy][1] and [Community Guidelines][2]) and procedures that may be published from time to time on this Site by Unconfigured Forum (collectively, the "Agreement").

Renders as:

The Website is offered subject to your acceptance without modification of all of the terms and conditions contained herein and all other operating rules, policies (including, without limitation, www.example.com’s Privacy Policy and Community Guidelines) and procedures that may be published from time to time on this Site by Unconfigured Forum (collectively, the “Agreement”).

The “www.example.com’s” link renders as a broken punycode link to http://www.example.com’s


(Jeff Atwood) #3

Wow that’s a major parser error, @eviltrout might even be worth a look.

Minimal repro is:

[link1](http://www.example.com) (a "blah").

link1 (a “blah”).

(edited: verified fix!)

Something about the parens and double quote block there at the end, perhaps it is being interpreted as the title caption for the link? Looks like it is… hover that link above.


(Jeff Atwood) #4

There’s no clean way to fix this in the text. I need to kill that double quoted string in the parens, and I can’t do that without adding a hacky " in there – or worse, changing the meaning of the document:

… on this Site by Unconfigured Forum (collectively, the “Agreement”).

We really need this fixed in the parser.


(Jens Maier) #5

I’ll have a look at this tomorrow, if I may. Maybe see if refactoring the block parser and reusing some of that code for the inline parser makes sense.

Looks like this is a known bug in upstream and has been around since October of last year: Bug when using inline link with a tittle · Issue #147 · evilstreak/markdown-js · GitHub
I’ve isolated the url match regexp in function link in better_markdown.js as the offending code. It consumes the closing paren as part of the URL even if it isn’t properly matched. JavaScript’s crippled regex engine strikes again…


(Robin Ward) #6

You absolutely may! Although I plan on looking at it on Monday if it’s still outstanding :slight_smile:


(Jens Maier) #7

Nope, done. Or… at least worked around.

https://github.com/discourse/discourse/pull/2688

My kingdom for a proper regex engine in JavaScript… *sigh*


(Jeff Atwood) #8