Switch exclusively to server-side Markdown rendering.

Review Request #6423 — Created Oct. 9, 2014 and submitted

Information

Review Board
release-2.0.x
4ac9b70...

Reviewers

When we introduced Markdown support, we had two renderers:
Python-Markdown (for the server side), and marked.js (for the client
side). Due to a number of issues in the marked.js rendering, this
resulted in some unsatisfactory rendered output in certain situations,
and required invasive escaping to work around other issues.

We no longer use marked.js (which will be removed in a separate change).
Instead, Markdown is rendered as part of the page, and as part of any
API responses (by using the force-text-type options in API requests).
This improves the perceived load time of the page, gives us consistency
in rendering, and will allow us to be a lot smarter about how we escape
and process Markdown in the future.

Some behavior has changed along with this, which should help fix cases
reported by users:

* Code blocks without a language identifier are no longer highlighted by
default, meaning that fenced or idented code blocks can now be used
for any plain text.

Unfortunately, this does mean that older text with code blocks will no
longer be highlighted unless they use a language identifier on a
fenced code block, but it's worth losing that to gain some
consistency.

* Text in code blocks will no longer be turned into links, and will no
longer be syntax-highlighted, making a plain fenced code block immune
to formatting.

In order to have access to the raw data for the inlineEditors, builtin
fields now have their raw data stored in the reviewRequestData for the
page, and custom fields have their raw data stored as data-raw-value=
attributes (which are then stored in extraData and removed from the
DOM on load).

This change should let us resolve a lot of the issues people have hit,
and provides a stepping stone for proper support for disabling Markdown
for a field.

Tested editing every type of field on a review request (including
custom ones), every type of comment, and replies to reviews.

This has not yet been tested with top-level comments or reviews,
since those are only ever rendered on-the-fly on master with the new
Review dialog. Separate changes will be made there to fix that up.

Tested these with and without rich_text=true in the database.

Tried adding code blocks using indentation, fences, and fences with
language IDs. Saw that only the ones with language IDs had any
highlighting.

Added various types of Markdown formatting and linkage to code blocks,
and saw that they never linked.

Unit tests on JavaScript and Python pass.

While I've tried to be extensive in my testing, I really would greatly
appreciate having more people go through and test every condition in
order to make sure I didn't miss something important.

david
  1. Ship It!

  2. 
      
chipx86
Review request changed

Status: Closed (submitted)

Change Summary:

Pushed to release-2.0.x (9b6f5a7)
Loading...