Page MenuHomePhabricator

Allow <sup> and <sub> in {{DISPLAYTITLE:}}
Closed, ResolvedPublic

Description

Please allow <sup> and <sup> in {{DISPLAYTITLE:}} as it is enabled for TOC headers.

It is totally reasonable to show correct form of indexes and it doesn't break copy'n'paste.


Version: unspecified
Severity: enhancement

Details

Reference
bz14226

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:10 PM
bzimport set Reference to bz14226.
bzimport added a subscriber: Unknown Object (MLST).

ayg wrote:

Quick patch, kind of fixes the problem but possibly introduces lots of fun XSS and not really tested

This makes the output of ParserOutput::getDisplayTitle() raw HTML, as is seemingly needed. However,

  1. This causes problems with the <title> of the page, which must be plain text in any event.

Also,

  1. The patch puts through *all* titles (not just display titles) as raw HTML, which is obviously wrong!
  1. Doesn't work for the edit page, or probably other places.

It seems like a better path would be to add a new variable mHtmlDisplayTitle or something, and use that for where raw HTML is acceptable, using the current one for <title>, as well as legacy uses.

attachment patch ignored as obsolete

rememberthedot wrote:

Proposed patch v1

Here is a preliminary patch that should help resolve the problem. It uses Sanitizer::removeHTMLtags, so it allows tags allowed in wikitext (like <sup> and <sub>) but not tags not allowed in wikitext (like <script>). This is very similar to what the English Wikipedia's JavaScript implementation already does (see [[MediaWiki:Common.js]]). I tested this patch on all skins and it appears to work OK.

Unlike the previous patch, this patch differentiates between the HTML title (what will go into <h1>) and the plain text title (what will go into <title>). This avoids problems with tags finding their way into <title> when <title> is not supposed to have any tags inside of it.

One of the limitations of this patch is that it doesn't process templates. It'd be nice if we could say {{DISPLAYTITLE:{{Unicode|unusual characters}}}}, including a template designed to improve browser compatibility with unusual characters. But this is a minor concern since I believe all the compatibility templates like this can be expressed as <span class="Unicode"> instead.

And of course, if nobody finds any major bugs with this patch, we could just implement it for now and worry about tweaking the code to be more permissive later.

Attached:

This is concrete special case of bug 12998. Please move the patch there and then mark this as duplicate.

rememberthedot wrote:

*** This bug has been marked as a duplicate of bug 12998 ***