* Safe template linter reports zero violations on modified files
* Removed some (or most) coffeescript-genereated returns
* Big HTML chunks in JS converted to underscore templates
* Markdown processor - safe tempate linter compatibility
* Fixed double escaping HTML tags in code blocks caused by passing it through postMathJaxProcessor twice
* Removing jQuery.ajax.beforeSend - it might be set globally and this code overrides it (part of 62fa253af6ee384f0766d72cd2d67bcf43697692)
* Avoid resetting Backbone history if already started (part of 9591b526bdd56163de0098099e46e44c566061f5)
* goHome no longer triggers thread:removed event - already triggered up the call stack (part of 9591b526bdd56163de0098099e46e44c566061f5)
* Avoid using beforeSend as it might be set globally (adapted from 2dfe104f3915efa546c85ef277eb75c5abb9b49b)
* Refactor triggering navigation to use constant/method instead of magic strings (part of 4843facd507b1cee8712bf10e96ff6c25c98bca2)
* Switching to using jQueyr.prop instead of jQuery.attr
* Fixed email notifications enable/disable (adapted from 8a7f022)
* Load thread if requested thread isn't loaded yet (adapted from e28dde32169b388235030dba945366f4c13e565f)
* Added ability to set custom css classes on search messages (adapted from b2e4c18905d7c7560838e264d6b218a3c4c6dc1f)
* Actually rerendering view with new model data when it is loaded/changed
rewriting them.
In PERF-341, we adjusted the static_replace middleware to try and
exclude static XBlock resource URLs from being interpreted as the marker
URLs used to signify course assets in course content. Since they both
started with /static, this could, and did, cause issues where linking
directly to the assets of an XBlock within, say, one of its templates,
would lead to that link being rewritten and ultimately being incorrect.
The fix attempted to see if the link started with the prefix that all
static XBlock resource URLs start, and if so, it returned them
unmodified.
We incorrectly assumed that our testing captured all cases, and since
we're here, we know that this was wrong. We weren't accounting for cases
when the URLs being generated had the STATIC_URL configuration value
prefixed -- https://example.com/static/xblock/.... -- and so our direct
check of seeing if such a URL started with "/static/xblock" would always
fail, leading to the erroneous rewriting and nonsensical output.
This fix checks if the link either starts with the prefix OR if it
starts with the STATIC_URL value and contains the prefix overall. There
is a small overlap between the STATIC_URL and the prefix we check for,
so an inconsistency could arise down the line if we changed our
STATIC_URL to use a difference base directory, but our tests will at
least catch the issue now.
