This popped up in Adam Davis's revision to this answer. Including the http://stackoverflow.com in the block quote seems to be creating a link that is never closed. Let's try to reproduce it here:


If the bug behaves as I suspect it does, this text will be part of the link. Well, that didn't do it, so forgive me as I include more of this text and try to pare it down to the problem...

Here is the email trail and a few notes on what occurred when per Rich B:

Rich's account is changed from Chet Atwood to Rich B by stackoverflow team, then Rich received this email:

SUBJECT: your avatar
FROM: stackoverflow team Fri, Nov 6, 2009 at 11:26 AM
TO: Chet Atwood
Please desist, or there will be consequences.



Rich responded:

SUBJECT: RE: your avatar
FROM: Chet Atwood Fri, Nov 6, 2009 at 12:58 PM
TO: stackoverflow team

Please desist what, precisely?

Oh yeah, that did it.

  • it worked. booya – belgariontheking Nov 12 '09 at 21:23
  • Yeah, I decided not to try and fiddle with it to find a way around it. It's annoying, and hopefully fixable, but I've run into far too many link-related markdown issues to care anymore. – Adam Davis 'ze-zir-zem' Nov 12 '09 at 21:27
  • Looks like you found a good workaround for the time being, though: "Put the stackoverflow URLs in backticks to fix the bizarre link bug." – Adam Davis 'ze-zir-zem' Nov 12 '09 at 21:28
  • Actually, it did do it in your first quote. The </a> is not in source, and in Firefox, I'm seeing everything from there til team@stackoverflow.com as a link. – John Rudy Nov 12 '09 at 21:59

This had to do with the legacy "encode email addresses" support in our markdown server-side processor.

Things like


technically get encoded to mailto: URLs in Markdown, but we've never really supported that (email, feh, I spit on email). But I never removed that support from the Markdown processor on the server, either, so it was still being emitted.

I removed it now since a) we weren't using it and b) it generates some dumb markup that causes issues.


The results

I ran several tests over the course of several edits, and discovered the following:

  1. The first time, the SO link did overflow, right up to my manually-inserted </a> tag.
  2. The second time, where I added the Google link, no overflow from Google, but SO still did.
  3. The third time, when I added all of the other Trilogy links, SO overflowed past my manual </a>, Google overflowed, the Meta link overflowed, and SU and SF did not overflow.

My gut reaction: This thing's freakin' unpredictable. It'll happen sometimes, or it won't, but the best way to use real links is to use MarkDown's syntax, and if you're embedding a URL in a quote, use the backtick method mentioned in the comments. I have no clue what this post will look like when I submit this fourth (and probably final) time.

The test

Here's a simple test. You can use your browser's "View Source" feature to see it in action:


And all this should be a link. Right up until ... here, where I manually insert a </a>.

OK, with that out of the way, is the problem just relegated to SO links, or can other links cause the problem too? Let's ... find out!


Is this still a link? Hrm ... Negative!

How about the other Trilogy sites?


Is this still a link? Hrm ...


Is this still a link? Hrm ...


Is this still a link? Hrm ...

  • On a completely unrelated note, I notice that the SU and SF links are nofollow'd. – mmyers Nov 12 '09 at 22:06
  • My results were observed in Firefox 3.5.5 on Windows 7, BTW. And regardless of browser behavior for handling the unclosed links, the links -- except SU and SF, for some reason! -- are all unclosed in the blockquote tags, if you view the page source. – John Rudy Nov 12 '09 at 22:08
  • @mmyers: I think all of the external links are nofollow'd. – John Rudy Nov 12 '09 at 22:08
  • Turns out my manual </a> was stripped; that'll do it. – John Rudy Nov 12 '09 at 22:09
  • 2
    Sooo... the lesson here is "basic HTML is hard, let's go shopping"? – Hilarious Comedy Pesto Nov 12 '09 at 22:17
  • I think the lesson is that MarkDown, while awesome, is hardly perfect. But we all already knew that. – John Rudy Nov 12 '09 at 22:31
  • this is actually a totally different bug than what the OP posted. – Jeff Atwood Nov 13 '09 at 6:04
  • Is this part of the [status-completed], or should it be reported separately? (And from the outside looking in, it looks like the same bug ... ) – John Rudy Nov 13 '09 at 14:30
  • "fixed" by making the tag balancing algorithm go in forward order when pairing and doing a second pass in reverse for orphan removal. Previously it did a 1-pass reverse. Details at refactormycode.com/codes/360-balance-html-tags – Jeff Atwood Nov 15 '09 at 12:19
  • Total fix; awesome. – John Rudy Nov 15 '09 at 17:13

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .