Page MenuHomePhabricator

Reference list produces errors if ParserClearState fires after <ref> tags, but before <references>
Open, MediumPublic

Description

Author: andru.public

Description:
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.


Version: master
Severity: normal

Attached:

Details

Reference
bz46349

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 1:32 AM
bzimport added a project: Cite.
bzimport set Reference to bz46349.
bzimport added a subscriber: Unknown Object (MLST).

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.

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.