Last modified: 2012-05-03 04:02:05 UTC

Wikimedia Bugzilla is closed!

Wikimedia has migrated from Bugzilla to Phabricator. Bug reports should be created and updated in Wikimedia Phabricator instead. Please create an account in Phabricator and add your Bugzilla email address to it.
Wikimedia Bugzilla is read-only. If you try to edit or create any bug report in Bugzilla you will be shown an intentional error message.
In order to access the Phabricator task corresponding to a Bugzilla report, just remove "static-" from its URL.
You could still run searches in Bugzilla or access your list of votes but bug reports will obviously not be up-to-date in Bugzilla.
Bug 20050 - Reference with numbered list triggers Tidy to corrupt reference list
Reference with numbered list triggers Tidy to corrupt reference list
Status: RESOLVED FIXED
Product: MediaWiki extensions
Classification: Unclassified
Cite (Other open bugs)
unspecified
All All
: Low enhancement with 1 vote (vote)
: ---
Assigned To: Nobody - You can work on this!
http://meta.wikimedia.org/w/index.php...
: patch, patch-need-review
Depends on:
Blocks: tidy
  Show dependency treegraph
 
Reported: 2009-08-03 11:12 UTC by Purodha Blissenbach
Modified: 2012-05-03 04:02 UTC (History)
8 users (show)

See Also:
Web browser: ---
Mobile Platform: ---
Assignee Huggle Beta Tester: ---


Attachments
Force "\n" at the end of each reference's text (1.92 KB, patch)
2011-11-11 14:18 UTC, Brad Jorsch
Details

Description Purodha Blissenbach 2009-08-03 11:12:19 UTC
When a reference has a numbered list inside, it depends on
wether or not it is terminated with a newline, wether or
not the references follwing it are correctly displayed.
See page:
http://meta.wikimedia.org/w/index.php?title=User:Purodha/bug_20050
for a sample. The last two references having numbered indents,
and show the difference.
Comment 1 Purodha Blissenbach 2009-08-03 11:25:30 UTC
Sorry, unclear wording. Correct is: 

References C and D are rendered incorrectly.
Reference B appears to cause this.
Reference A has an extra newline at its end, which Reference B hasn't.

Reference A does not influence how references following it are rendered.

Evereything else is demonstrating that, only rumbered lists are
influential.
Comment 2 Gadget850 2010-05-22 12:09:33 UTC
http://en.wikipedia.org/wiki/Help:Cite_errors/Testcases7

Nesting an ordered list inside another ordered list. Not terminating with a newline causes the rest of the list to be wrapped in an unordered list. I would not be surprised if this was an interaction with HTML Tidy.
Comment 3 Platonides 2010-05-22 12:18:25 UTC
You are right. The <ul> is caused by Tidy. MediaWiki outputs </li></ol> instead of </ol></li>, and Tidy tries to fix it by opening a <ul>.
Comment 4 Happy-melon 2010-05-24 19:29:08 UTC
Confirmed as a(nother) bad interaction with Tidy; unTidy'd output is correct.
Comment 5 Gadget850 2010-05-24 20:03:10 UTC
Guess we can close this and track it at Bug 2542 as a Tidy issue.
Comment 6 Platonides 2010-05-24 20:04:26 UTC
> Confirmed as a(nother) bad interaction with Tidy; unTidy'd output is correct.

It is not correct, or Tidy wouldn't need to fix us.
Comment 7 Brad Jorsch 2011-11-09 22:05:29 UTC
This has little to do with Cite. It's mostly the parser being simplistic combined with Tidy making a bad "fix".

As far as Cite is concerned, the ref with the embedded list gets expanded to wikitext something like this:

    <LI id="cite_note-0">[[#cite_ref-0|↑]] This is a reference with a numbered list
    # line 1
    # line 2
    # line 3— no newline</LI>

I've capitalized the <li></li> tags to make the next step clearer.

That gets handed to the parser, which doesn't pay any attention to the HTML. doBlockLevels just blindly converts the wiki-list by inserting "<ol><li>" in place of the "#" for the first element, "</li><li>" in place of the "#" for all subsequent elements, and "</li></ol>" after the last list element. The </LI> from Cite winds up inside the last list element:

    <LI id="cite_note-0"><a href="#cite_ref-0">↑</a> This is a reference with a numbered list
    <ol><li> line 1
    </li><li> line 2
    </li><li> line 3— no newline</LI>
    </li></ol>

Tidy apparently decides that the last </li> is closing the <LI> and inserts a "missing" </ol>, and then the real </ol> is interpreted as closing the <reference>'s list. And then the <li> for the next reference gets a "missing" <ul> inserted before it. A browser given this tag soup might do the same, or it might decide that last </li> is extraneous and then insert the missing </li> when it sees the "<li>" for the next ref.

The reason it works with the newline is because the </LI> is then after the list instead of inside the last element, so when the parser inserts its "</li></ol>" it winds up before the </LI> and everything is correct.

We ''could'' work around this in Cite by changing [[MediaWiki:cite_references_link_one]] and [[MediaWiki:cite_references_link_many]] to have a newline before the </li>, or we could insert a newline at the end of the string passed as $3 to these messages.
Comment 8 Gadget850 2011-11-10 10:30:25 UTC
That works. See test at 

http://test.wikipedia.org/wiki/User:Gadget850/Ordered_lists_in_references
Comment 9 Gadget850 2011-11-10 13:18:22 UTC
Now implemented on en.wiki.
Comment 10 Erwin Dokter 2011-11-10 18:54:27 UTC
Yes, but better is to fix this in cite.php. If a linebreak is all that is needed, I'll see if I can come up with a patch.
Comment 11 Erwin Dokter 2011-11-10 19:04:34 UTC
PHP is a little out of my league, but somewhere in function referencesFormatEntry in Cite_body.php, a \n needs to be inserted.
Comment 12 Brad Jorsch 2011-11-11 14:18:27 UTC
Created attachment 9420 [details]
Force "\n" at the end of each reference's text

(In reply to comment #11)
> PHP is a little out of my league, but somewhere in function
> referencesFormatEntry in Cite_body.php, a \n needs to be inserted.

Several places, actually. The attached patch is slightly more complex, in that it forces exactly one newline at the end of the reference body whether that ref is 

    <ref>foo</ref>

or something ridiculous like

    <ref>foo



    </ref>
Comment 13 Sumana Harihareswara 2011-11-11 14:19:48 UTC
Added "patch" and "need-review" keywords to signal that this patch awaits code review.  Thanks for the patch, Brad.
Comment 14 Roan Kattouw 2011-11-14 12:03:37 UTC
Thanks for the patch. I tested it with the reporter's test case mentioned in comment 0 and it worked fine. Applied in r102970.
Comment 15 Gadget850 2012-05-03 04:02:05 UTC
Confirmed: fixed; deployed in 1.20

Note You need to log in before you can comment on or make changes to this bug.


Navigation
Links