17

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.

11
  • No-repro in 5.0.376 (44230), so apparently 6-specific Sep 3, 2010 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. Sep 3, 2010 at 5:36
  • 5
    @rchern still not our bug, though Sep 3, 2010 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. Sep 3, 2010 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, 2010 at 15:45
  • @Dan, still broken in dev version. Oct 6, 2010 at 1:40
  • It works for me, chrome v. 6.0.472.63
    – default
    Oct 18, 2010 at 22:05
  • It happens in Chrome 7 as well. Oct 21, 2010 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, 2010 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. Nov 10, 2010 at 18:32
  • FYI still a problem years later. Just updated to iOS version 33.0.1750.21
    – Bohemian
    Mar 28, 2014 at 4:45

4 Answers 4

18

EDIT

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/)) {
    "X".match(/()./);
}

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.

9
  • 2
    Wow, awesome work. Did you report this to Google, by any chance? If not I guess I will.
    – Dan Tao
    Sep 29, 2010 at 4:57
  • @Dan I added a comment on the ticket, will be more than happy to help them test.
    – waffles
    Sep 29, 2010 at 5:08
  • 3
    well done Sam! twitter.com/caseyf/status/25884170779 Sep 30, 2010 at 0:21
  • The Chromium project gotta huge backlog. Reports won't be processed for months. Oct 2, 2010 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, 2010 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, 2010 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, 2010 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, 2010 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, 2011 at 7:33
7

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.

4
  • Don't you just wish all browsers were the same? Especially Internet Explorer? Sep 3, 2010 at 6:24
  • 2
    Every browser is equal, but some browsers are more equal than others. Sep 18, 2010 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, 2010 at 22:06
  • This happens on Chrome 7 as well. Oct 21, 2010 at 17:58
4

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
  _8.wrap(_a,_2.wmd_env.lineLength-2);

  _a.selection=_a.selection.replace(/^/gm,"> ");
  _13(true);
  _a.skipLines();
}else{
5
  • Darn you, _2!
    – badp
    Sep 13, 2010 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, 2010 at 15:43
  • This is actually not the problem ... see my answer
    – waffles
    Sep 29, 2010 at 4:22
  • awesome, waffles. Damn, I can't downvote myself.
    – outcassed
    Sep 29, 2010 at 13:46
  • this actually helped me narrow down the problem. Thanks heaps!
    – waffles
    Sep 30, 2010 at 0:24
2

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

it can be fixed as below:

Expected output:

Blockquote

What happens instead:

Blockquote

Blockquote> BlockquoteBlockquote

Blockquote

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/)) {
        "X".match(/()./)
    }
    
  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 .