Last modified: 2013-04-16 19:42:47 UTC

Wikimedia Bugzilla is closed!

Wikimedia migrated from Bugzilla to Phabricator. Bug reports are handled in Wikimedia Phabricator.
This static website is read-only and for historical purposes. It is not possible to log in and except for displaying bug reports and their history, links might be broken. See T48349, the corresponding Phabricator task for complete and up-to-date bug report information.
Bug 46349 - Reference list produces errors if ParserClearState fires after <ref> tags, but before <references>
Reference list produces errors if ParserClearState fires after <ref> tags, bu...
Status: UNCONFIRMED
Product: MediaWiki extensions
Classification: Unclassified
Cite (Other open bugs)
master
All All
: Normal normal (vote)
: ---
Assigned To: Nobody - You can work on this!
: patch, patch-need-review
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2013-03-20 08:30 UTC by Andru
Modified: 2013-04-16 19:42 UTC (History)
2 users (show)

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


Attachments
Git patch; adds a $mDoneReferences boolean to determine if <references> has been parsed, (1.37 KB, patch)
2013-03-20 08:30 UTC, Andru
Details

Description Andru 2013-03-20 08:30:38 UTC
Created attachment 11960 [details]
Git patch; adds a $mDoneReferences boolean to determine if <references> has been parsed,

I have tested and found this bug is present in master and REL1_20.

If ParserClearState fires after <ref> tags have been parsed, but before the <references> tag has been parsed, Cite resets the stack and thus when rendering <references> will either fail to display references or will output the "<ref> tag with name [] defined in <references> is not used in prior text" error.

I have a use case of this. I haven't identified *why* ParserClearState is being fired.

I'm attaching a patch which solves this by adding a boolean which is set after the references tag has been processed, ensuring that Cite doesn't reset until *after* <references> has been rendered.

Since I don't entirely understand the design decision to reset on ParserClearState, I'm not sure if this will have unintended consequences and would appreciate some advice.

If it looks good, I'll submit a change on gerrit.
Comment 1 Andre Klapper 2013-03-20 09:32:58 UTC
Hi! Thanks for your patch!

You are welcome to use Developer access
  https://www.mediawiki.org/wiki/Developer_access
to submit this as a Git branch directly into Gerrit:
  https://www.mediawiki.org/wiki/Git/Tutorial

Putting your branch in Git makes it easier to review it quickly.
Thanks again! We appreciate your contribution.
Comment 2 Brad Jorsch 2013-04-16 19:42:47 UTC
The reason for resetting on ParserClearState is exactly that: the parser is clearing the state to start a brand new parse, and shouldn't be carrying over references from a previous parse.

Rather than papering over the problem by having Cite refuse to clear, it would probably be a much better idea to figure out the underlying cause of the call to ParserClearState. Instructions so anyone else can reproduce the problem would be helpful, too.

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


Navigation
Links