Skip to main content
replaced http://meta.stackexchange.com/ with https://meta.stackexchange.com/
Source Link

While testing this related bugthis related bug, I noticed that trying to make a link to a URL (technically, an IRI) using raw Markdown link syntax crashed the Markdown editor hard, permanently disabling Markdown preview until the page is reloaded(!).

Steps to reproduce:

  1. Paste the following string into the Markdown editor (outside a code block):

     [](https://en.wikipedia.org/wiki/😃)
    
  2. Observe that the preview pane freezes, and no longer updates (even if you remove the link).

The cause of this crash is the same as for the other bugthe other bug, i.e. trying to URL-encode individual halves of a UTF-16 surrogate pair, although it occurs in a different part of the code. Specifically, the crash happens in the sanitizeTag() function, in the following code:

return prefix + url.replace(/[^-A-Za-z0-9+&@#\/%?=~_|!:,.;\(\)*[\]$]/g, function (c) {
    anyChange = true;
    if (c == "'") // this is the only character that isn't in our whitelist and that is returned unchanged by encodeURIComponent()
        return "%27";
    else
        return encodeURIComponent(c);
    
});

Note that, even if the regexp is fixed to correctly match UTF-16 surrogate pairs as single characters, a crash might still be triggered by pasting in actual mismatched surrogates. While these are not valid Unicode, we probably should handle them more gracefully than by crashing the editor.

Also, I have not yet tested whether a similar problem also occurs in the server-side Markdown parsing code. If it does, that would be a much more serious issue.

While testing this related bug, I noticed that trying to make a link to a URL (technically, an IRI) using raw Markdown link syntax crashed the Markdown editor hard, permanently disabling Markdown preview until the page is reloaded(!).

Steps to reproduce:

  1. Paste the following string into the Markdown editor (outside a code block):

     [](https://en.wikipedia.org/wiki/😃)
    
  2. Observe that the preview pane freezes, and no longer updates (even if you remove the link).

The cause of this crash is the same as for the other bug, i.e. trying to URL-encode individual halves of a UTF-16 surrogate pair, although it occurs in a different part of the code. Specifically, the crash happens in the sanitizeTag() function, in the following code:

return prefix + url.replace(/[^-A-Za-z0-9+&@#\/%?=~_|!:,.;\(\)*[\]$]/g, function (c) {
    anyChange = true;
    if (c == "'") // this is the only character that isn't in our whitelist and that is returned unchanged by encodeURIComponent()
        return "%27";
    else
        return encodeURIComponent(c);
    
});

Note that, even if the regexp is fixed to correctly match UTF-16 surrogate pairs as single characters, a crash might still be triggered by pasting in actual mismatched surrogates. While these are not valid Unicode, we probably should handle them more gracefully than by crashing the editor.

Also, I have not yet tested whether a similar problem also occurs in the server-side Markdown parsing code. If it does, that would be a much more serious issue.

While testing this related bug, I noticed that trying to make a link to a URL (technically, an IRI) using raw Markdown link syntax crashed the Markdown editor hard, permanently disabling Markdown preview until the page is reloaded(!).

Steps to reproduce:

  1. Paste the following string into the Markdown editor (outside a code block):

     [](https://en.wikipedia.org/wiki/😃)
    
  2. Observe that the preview pane freezes, and no longer updates (even if you remove the link).

The cause of this crash is the same as for the other bug, i.e. trying to URL-encode individual halves of a UTF-16 surrogate pair, although it occurs in a different part of the code. Specifically, the crash happens in the sanitizeTag() function, in the following code:

return prefix + url.replace(/[^-A-Za-z0-9+&@#\/%?=~_|!:,.;\(\)*[\]$]/g, function (c) {
    anyChange = true;
    if (c == "'") // this is the only character that isn't in our whitelist and that is returned unchanged by encodeURIComponent()
        return "%27";
    else
        return encodeURIComponent(c);
    
});

Note that, even if the regexp is fixed to correctly match UTF-16 surrogate pairs as single characters, a crash might still be triggered by pasting in actual mismatched surrogates. While these are not valid Unicode, we probably should handle them more gracefully than by crashing the editor.

Also, I have not yet tested whether a similar problem also occurs in the server-side Markdown parsing code. If it does, that would be a much more serious issue.

Source Link
Ilmari Karonen
  • 31.8k
  • 5
  • 92
  • 168

Non-BMP Unicode character in URL crashes the Markdown editor

While testing this related bug, I noticed that trying to make a link to a URL (technically, an IRI) using raw Markdown link syntax crashed the Markdown editor hard, permanently disabling Markdown preview until the page is reloaded(!).

Steps to reproduce:

  1. Paste the following string into the Markdown editor (outside a code block):

     [](https://en.wikipedia.org/wiki/😃)
    
  2. Observe that the preview pane freezes, and no longer updates (even if you remove the link).

The cause of this crash is the same as for the other bug, i.e. trying to URL-encode individual halves of a UTF-16 surrogate pair, although it occurs in a different part of the code. Specifically, the crash happens in the sanitizeTag() function, in the following code:

return prefix + url.replace(/[^-A-Za-z0-9+&@#\/%?=~_|!:,.;\(\)*[\]$]/g, function (c) {
    anyChange = true;
    if (c == "'") // this is the only character that isn't in our whitelist and that is returned unchanged by encodeURIComponent()
        return "%27";
    else
        return encodeURIComponent(c);
    
});

Note that, even if the regexp is fixed to correctly match UTF-16 surrogate pairs as single characters, a crash might still be triggered by pasting in actual mismatched surrogates. While these are not valid Unicode, we probably should handle them more gracefully than by crashing the editor.

Also, I have not yet tested whether a similar problem also occurs in the server-side Markdown parsing code. If it does, that would be a much more serious issue.