Please star this ticket rchern helpfully created to help have the bug addressed:

Issue 56095: Markdown behavior since v6 branch

Well, I would just bump up this question with an edit, but my meta rep isn't high enough. So I'm posting this as a new question.

Here's the problem: in the latest stable version of Google Chrome (6.0.472.53) -- now out of beta -- clicking on the "Blockquote" button in the editor results in a strange textual anomaly.

Below are a couple of screenshots illustrating this issue.

Before clicking the Blockquote button Before clicking the Blockquote button

After clicking Blockquote button After clicking Blockquote button

Steps to reproduce:

  1. Using the latest stable version of Chrome, navigate to StackOverflow.
  2. Open up any page with an editor in it -- either to answer a question or to ask a new question.
  3. Type and select some text in the editor.
  4. Click on the Blockquote button.

The above strange effect above always happens, as far as I can tell.

The main reason I am posting this is that the accepted answer to the previous question I linked to was "Beta browsers are not supported"; and Chrome 6 is now out of beta.

  • No-repro in 5.0.376 (44230), so apparently 6-specific – Michael Mrozek Sep 3 '10 at 5:15
  • 3
    I couldn't help it, I totally thought "HA!!" seeing this is in the stable version now. Yes, shame on me. – Rebecca Chernoff Sep 3 '10 at 5:36
  • 5
    @rchern still not our bug, though – Jeff Atwood Sep 3 '10 at 6:10
  • @Jeff, I've gone through the code a couple times digging deeper to get to the root, but I haven't gotten to the end yet. – Rebecca Chernoff Sep 3 '10 at 16:53
  • There also seems to be a problem with the "link" control - if you have a link that is followed by some other text, and you select your link text and use the link button on it, things go weird... – outcassed Sep 15 '10 at 15:45
  • @Dan, still broken in dev version. – Rebecca Chernoff Oct 6 '10 at 1:40
  • It works for me, chrome v. 6.0.472.63 – Default Oct 18 '10 at 22:05
  • It happens in Chrome 7 as well. – Michael Pryor Oct 21 '10 at 17:59
  • I implemented this workaround for 6 only, I don't really want to reinstate it for 7 .... but if I have to ... – waffles Oct 22 '10 at 12:04
  • 1
    Re-open & stop declining. If this is a bug in Chrome excercised by the Stack Overflow code, then Stack Overflow should be the one to report it to Google, not SO's users. Users of my software don't care if something doesn't work because of a bug in my software or in Windows, they just want it fixed. – John Dibling Nov 10 '10 at 18:32
  • FYI still a problem years later. Just updated to iOS version 33.0.1750.21 – Bohemian Mar 28 '14 at 4:45


Secretly I added the workaround for chrome 6 only, I upgraded to chrome 7 today and the bug is back. I really don't want to make this workaround part of WMD.

Ok, this happens cause of a pretty serious bug in the Chrome 6 regular expression engine.

Under certain circumstances it fails to set back references properly. So we have this code:

this.selection = this.selection.replace(/(^\n*)/, "");
// In Chrome 6 RegExp.$1 is set to the previous match eg: ("whatever") instead of being empty   
this.startTag = this.startTag + RegExp.$1;

My workaround is to add:

if (navigator.userAgent.match(/Chrome\/6/)) {

this.selection = this.selection.replace(/(^\n*)/, "");

Of course this is totally horrid, and should be fixed in the web browser.

In fact it is so bad I do not want to include this in wmd.js

This bug also happens to be a heisenbug, when debugging it if your first breakpoint is too early, stepping through shows that everything is good.

  • 2
    Wow, awesome work. Did you report this to Google, by any chance? If not I guess I will. – Dan Tao Sep 29 '10 at 4:57
  • @Dan I added a comment on the ticket, will be more than happy to help them test. – waffles Sep 29 '10 at 5:08
  • 3
    well done Sam! twitter.com/caseyf/status/25884170779 – Jeff Atwood Sep 30 '10 at 0:21
  • The Chromium project gotta huge backlog. Reports won't be processed for months. – Henrik P. Hessel Oct 2 '10 at 12:39
  • Sam - do you have a test case that illustrates the bug? I'm guessing that "Markdown behavior since v6 branch" will probably be ignored forever but maybe a bug filed for V8 (presumably that's where the problem is) that says "Regular expression engine fails to set backreferences properly under some conditions" with a test attached might have better luck. PS - thanks for the workaround. – outcassed Oct 26 '10 at 14:59
  • @casey, cheers, the only test case I have is all wmd, I have not stripped it down to something minimal. My concern here is that it could take a whole day to get a smaller test case. – waffles Nov 5 '10 at 5:51
  • 2
    Sam, would something like this be a more viable workaround? It could take ages for this bug to be fixed in V8. – Andy E Nov 10 '10 at 13:49
  • 1
    Decided to test it myself - looked at the wmd.js code and managed to fix it. pastebin.com/HKgYrzu3 is the code I used, pasted it into Chrome's console and it worked great. – Andy E Nov 10 '10 at 16:33
  • wow you are the best. Anyway there was a similar issue with the trimWhitespace function of the wmd and I solved it y adding your code. – Amila Jan 26 '11 at 7:33

Chrome 5: works OK
Firefox 3.6.x: works OK
IE8: works OK
Opera 10: works OK
Safari 5: works OK

Unfortunately, this is a bug in Chrome 6 (final), and should be reported to Google.

Don't get me wrong, I love Chrome -- it is my browser of choice and I am just as excited as anyone else to have a sweet new version -- but this really is not our bug.

  • Don't you just wish all browsers were the same? Especially Internet Explorer? – uɐɯsO uɐɥʇɐN Sep 3 '10 at 6:24
  • 2
    Every browser is equal, but some browsers are more equal than others. – Toon Krijthe Sep 18 '10 at 9:46
  • I just tested on Google Chrome 6.0.472.63 and it works fine :) So I guess you can add it to your list now. – Default Oct 18 '10 at 22:06
  • This happens on Chrome 7 as well. – Michael Pryor Oct 21 '10 at 17:58

The problem seems to be happening in the wrap() call in doBlockquote.

Oddly, if I comment it out, the problem goes away and blockquote seems to works correctly in Chrome 6. I'm working with the obfuscated version of WMD and I haven't got the patience to chase down what is really happening here.

if(/^(?![ ]{0,3}>)/m.test(_a.selection)){
  // comment out the following line and all is good in Chrome 6

  _a.selection=_a.selection.replace(/^/gm,"> ");
  • Darn you, _2! – badp Sep 13 '10 at 14:26
  • I'm using WMD on my own site so I started a bounty in hopes that someone else will feel like taking a look. Also noted in a comment on the question - there is an issue with the link control as well. – outcassed Sep 15 '10 at 15:43
  • This is actually not the problem ... see my answer – waffles Sep 29 '10 at 4:22
  • awesome, waffles. Damn, I can't downvote myself. – outcassed Sep 29 '10 at 13:46
  • this actually helped me narrow down the problem. Thanks heaps! – waffles Sep 30 '10 at 0:24

This indeed is a bug to be fixed by the Chrome.

it can be fixed as below:

Expected output:


What happens instead:


Blockquote> BlockquoteBlockquote


The fix:

  1. Search the file for "wmd.Chunks.prototype.addBlankLines = function"

  2. Within this function locate where two variables are assigned:

"var regexText; var replacementText;"

  1. Just after these variables add the following IF statement:

    if (navigator.userAgent.match(/Chrome/)) {
  2. This fixes the chrome issue with block quotes and is the fix currently implemented by StackOverflow.com.

You must log in to answer this question.

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