Page MenuHomePhabricator

Media Viewer embed code breaks links to Wikipedias
Closed, ResolvedPublic


Please have a look at the embed code at The links to German Wikipedia do not work, because the scheme ("http:") is missing. This makes reusers unable to embed this code easily, especially since this is a fairly subtle bug.

Event Timeline

Thanks for reporting this. Please provide steps to reproduce (how exactly to "have a look at the embed code"). I don't find any "embed" in the source of that page that you linked to.

Related: Commons:Forum#Ich geb nicht auf und frag nochmal: Kann mir jemand erklären, was der Mist soll? (in German)

The html-embedding-code for this file from the MediaViewer is:

<p><a href=""><img alt="Hh-strafjustizgebaeude-justitia.jpg" src="" height="514" width="787"></a><br>Von <a href="" class="extiw" title="de:Benutzer:Staro1">Staro1</a> - Von <a href="" class="extiw" title="de:Benutzer:Staro1">Staro1</a> in deutschsprachige Wikipedia geladen., <a title="Creative Commons Attribution-Share Alike 3.0<p></p>" href="">CC BY-SA 3.0</a>,</p>

If you check (an archive of where the code was copy&pasted, it appears that (following @Raymond at Commons Forum) the


(right after "(...) Share Alike 3.0") breaks the visual, creating an eventual redundant, empty paragraph.

But, if you copy&pasted the code into a html-tester like or it looks fine...

The missing


appears to be unrelated, as the code & links are working at above test pages.

I created HTML embed codes via MediaViewer for a bunch of Commons images. It looks like the superflous


appears only for images that uses Template:Cc-by-sa-3.0-migrated. Reason still unclear.

Yeah, great! Thanks to @Tgr for the weekend work :-)

Having protocol-relative links (starting with //) means that when the reader clicks them, whatever protocol they are using gets prepended. That's not ideal but should work as Commons is reachable through both protocols.

The <p></p> was provided by the template (fixed, although I am not sure why a single newline did that in the first place) but MV should sanitize it and use entities instead of <>.

FWIW, curid is the page id, not the revision id (which would be oldid), so it always links to the latest version of the page and is only used to make the URL shorter. Not sure if it makes sense to use it for HTML descriptions (it was mainly meant for plaintext which used to be horrendously long) but at least it should be linked.

Change 295120 had a related patch set uploaded (by Gergő Tisza):
Filter HTML from some attributes

Change 295126 had a related patch set uploaded (by Gergő Tisza):
Make embed text short URL into a link in HTML mode

The protocol-relative URLs are from markup like [[:de:Benutzer:Staro1|Staro1]] which the parser turns into <a href="//" class="extiw" title="de:Benutzer:Staro1">Staro1</a>. There are several ways to fix this:

The last remaining issue with sanitization seems to be a jQuery bug:

var $x = $('<span><a href="">x</a></span>');
$x.find('a').prop('title', 'a<p>b</p>c');
$x.html() // <a href="" title="a<p>b</p>c">x</a>

Upstreamed as

Change 295120 merged by jenkins-bot:
Filter HTML from some attributes

Please remove this tag when you have addressed the minor comment.

Change 295126 merged by jenkins-bot:
Make embed text short URL into a link in HTML mode

I think this is fixed. @Tgr can you confirm?

Tgr claimed this task.

Yup, fixed.