The visual editor can't reliably see references produced by templates, so it's possible to create auto-numbered refs with names that conflict with those coming from a template.
This task is limited to detecting the conflicts, we don't need to actually support reuse here.
Example page: https://en.wikipedia.beta.wmflabs.org/wiki/User:Adamw/RefColonZeroFromTemplate
Steps to reproduce:
- Open the example page for editing.
- Open the cite reuse dialog.
- Only the existing document ref is listed in the dialog.
- Add a re-use of the existing document ref.
- Save changes.
What happens
Your new ref will have the name ":0", despite this name colliding with the transcluded ref.
What should have happened
The new refs should have been given the name ":1".
Technical notes
Currently, it seems that elements produced by a template don't show up in VE's internalList or other data structures which hold the page content. The templates probably show up under the "mw:Transclusion" portion of the list.
Changing the data storage is the least-desirable solution. If possible, we want Cite to look into the DOM subtrees produced by transclusions and for those to be added to the list of refs for reuse, and to use the list of names to prevent collision.
In T214241: data-mw info is clobbered by template annotations we learned that references from transclusions are missing metadata, when the ref is produced at the top level of a template. If it's contained in another element in the template, then the metadata is theoretically available but still currently invisible to VE.
Test can make an API call to fetch the saved document's contents: eg. https://en.wikipedia.org/w/api.php?action=query&prop=revisions&titles=API&rvslots=*&rvprop=content&formatversion=2
Looks like template-generated blocks do generate full DOM information as part of Parsoid output, but this inner structure disappears in the VE model. We may have to include the transcluded elements as well, or at least access as supplemental info.