I was just editing a Stack Overflow question I had answered via the Android app. There I used the rather new feature of these editing buttons. I marked some text (after adding a second space at the end of each line to allow linebreaking) and selected 'format as blockquote'

The result? Some text with broken formatting and previously nonexistant literal 'null' in it:

screen shot

For reference: this is the question

  • Not repro'd on Nexus 5, Android 6.0.1, SE app v1.0.82 (beta), the texts were indented by 4 spaces. Could you try to repro this again? – Meta Andrew T. Jan 21 '16 at 9:20
  • @Anderew I can repro but I am still on 1.81, so it might well have been fixed – Vogel612's Shadow Jan 21 '16 at 10:40

This will be fixed in 1.0.84.

There were actually a series of bugs messing things up here:

  1. We weren't properly recognizing that the text wasn't in a quote. We use the regular expression /^(?![ ]{0,3}>)/m to check that no lines start with a >, but this was incorrectly used in String.matches which validates that the whole string matches making the multiline flag kind of useless. Now we validate with Pattern.compile("^(?![ ]{0,3}>)").matcher(selection).find()

  2. Our code for unwrapping markdown strings hit a undefined behavior. We use the regular expression /([^\n])\n(?!(\n|(?:\s{4,}|\s*>|\s*-\s+|\s*\d+\.|=|\+|-|_|\*|#|\s*\[[^]]+\]:)))/gm with $1 $2 to convert things like Hello World to Hello World before adding >. The second group in the expression is inside a negative lookahead which means it should never exist. JavaScript and Objective-C gives us the equivalent of an empty string here but Java gives us null. Since we know $2 will always be blank, I updated the replacement to $1 and all is well.

  3. After unwrapping, we rewrap to 70 characters wide. This code had some issues where it would incorrectly replace lower lines with upper lines. This wasn't really hit before because the code never got this far, but that was a problem.

  4. The unwrapping code from 2 did not consider \r. This caused \r\n\r\n to eventually transform to \n> \r> \n> \r>. This isn't the biggest problem because the Markdown processor could handle it, but Android doesn't render stray \r as a line break so it looked like you had lines starting with > >. (iOS actually renders them as new lines which has made this bug elusive there.) Now when unwrapping, we drop carriage returns in the selection entirely.

You must log in to answer this question.

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