Page MenuHomePhabricator

<abbr> with a link inside and another link next to it renders incorrect HTML output
Closed, InvalidPublic

Description

Reported at the Support Desk.

I've tested this on current master, on 1.28, 1.27 and 1.25 with the same results. However, I'm unable to reproduce this on WMF wikis.

Minimal test case: Try to parse this:

<abbr>[[x]]</abbr> [[y]]

(convenient URL fragment for Special:ApiSandbox): /Special:ApiSandbox#action=parse&format=json&text=<abbr>[[x]]<%2Fabbr>+[[y]]&prop=text|parsetree&disablelimitreport=1

This results in:

{
    "warnings": {
        "parse": {
            "*": "No \"title\" or \"contentmodel\" was given, assuming wikitext."
        }
    },
    "parse": {
        "title": "API",
        "pageid": 0,
        "text": {
            "*": "<p><abbr></a><a href=\"/index.php?title=X&amp;action=edit&amp;redlink=1\" class=\"new\" title=\"X (la p\u00e1gina no existe)\">x</a><abbr></abbr> <a href=\"/index.php?title=Y&amp;action=edit&amp;redlink=1\" class=\"new\" title=\"Y (la p\u00e1gina no existe)\">y</a>\n</p>"
        },
        "parsetree": {
            "*": "<root>&lt;abbr&gt;[[x]]&lt;/abbr&gt; [[y]]</root>"
        }
    }
}

As you can see, after the opening <abbr>, there's a closing </a> (!) and after the second closing </a> there's an empty <abbr></abbr>

Issue not reproducible with only one link.

There seems to be a similar issue reported on T24905 but fixed long ago.

Event Timeline

Izno subscribed.

The reported problem is probably due to Tidy configuration. That should have been your first question :P. On en.wp this works as expected and probably did then and does now due to Tidy and Remex, respectively.

Since Remex will be default-on sooner or later, I think we can safely resolve this.

Nope, I am not using Tidy. Still reproducible on 1.30 and 1.31.

I expect Tidy to fix invalid input from the user. But in this case, the input is valid, but MediaWiki is producing bad output, which in turn WMF Tidy is fixing (!).

ssastry subscribed.

Nope, I am not using Tidy. Still reproducible on 1.30 and 1.31.

I expect Tidy to fix invalid input from the user. But in this case, the input is valid, but MediaWiki is producing bad output, which in turn WMF Tidy is fixing (!).

Not reproducible on mediawiki master and not reproducible on mediawiki 1.31.

[subbu@earth:~/work/wmf/mediawiki] echo '<abbr> [[Foo]] </abbr> [[Bar]]' | php maintenance/parse.php
parse.php: warning: reading wikitext from STDIN. Press CTRL+D to parse.

<div class="mw-parser-output"><p><abbr> <a href="/wiki/index.php?title=Foo&amp;action=edit&amp;redlink=1" class="new" title="Foo (page does not exist)">Foo</a> </abbr> <a href="/wiki/index.php?title=Bar&amp;action=edit&amp;redlink=1" class="new" title="Bar (page does not exist)">Bar</a>
</p></div>

[subbu@earth:~/work/wmf/mediawiki] git branch
* (HEAD detached at 1.31.0)

Note that the above parse is without Tidy. So, the parser is not generating invalid HTML.

Please open a new ticket with more details specific to your configuration and/or verify that you are testing the right thing.

Okay, I tested on a wiki I though it was on 1.31, but no. It was on 1.30.

It's perfectly reproducible on 1.30 (I have no libtidy, so there's no way I can have tidy enabled). However, since on 1.31 it doesn't happen anymore (I've tested that now) this is indeed fixed.

Okay, I tested on a wiki I though it was on 1.31, but no. It was on 1.30.

It's perfectly reproducible on 1.30 (I have no libtidy, so there's no way I can have tidy enabled). However, since on 1.31 it doesn't happen anymore (I've tested that now) this is indeed fixed.

Yay! :D