Auto-generated <references /> list can't be moved in VE.
Closed, ResolvedPublic1 Story Points

Description

How to:

  1. create a sandbox with some footnotes; do not add a reflist
  2. save: the reflist is displayed at the bottom of the page
  3. edit the page and create two section titles (or some text). Move the reflist block between the two sections titles.
  4. save the page

Expectation: the reflist is displayed between the two sections titles.
Result: the reflist is still at the bottom of the page.

Based on this feedback (fr).

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptDec 20 2016, 2:51 PM

I've done a video to show some examples : https://www.youtube.com/watch?v=0xQvxwVJri4

Jdforrester-WMF renamed this task from Automatically included Reflist is movable on VE, but doesn't stay where it is placed to If the user edits an automatic references list, drop the "autoGenerated" attribute so it's serialised rather than ignored.Feb 28 2017, 8:11 PM
Jdforrester-WMF triaged this task as Normal priority.
Jdforrester-WMF set the point value for this task to 1.
Jdforrester-WMF moved this task from To Triage to TR1: Releases on the VisualEditor board.
Izno moved this task from Unsorted backlog to External on the Cite board.Mar 2 2017, 12:49 PM

Change 384757 had a related patch set uploaded (by DLynch; owner: DLynch):
[mediawiki/extensions/Cite@master] MWReferencesList: drop autoGenerated attribute if changed

https://gerrit.wikimedia.org/r/384757

Copying my comment from the duplicate bug:

This seems like a Parsoid issue. If we send back a reference list with autoGenerated:true it should get expanded to wikitext if it isn't in the place Parsoid expects it to be.

On investigation it looks like Parsoid has no inbound handling of autoGenerated. It was originally added so that VE could identify content to strip when parsing fragments (e.g. we convert a snippet of '<ref>foo</ref>' to HTML and want to insert in to a document, we should strip the auto-generated ref list).

The reason <references/> tags don't get auto-added on every edit is probably selective serialisation (selser). The reason the above patch appears to work is because if we change the 'autoGenerated' attribute that appears as a change to the section and triggers selser to re-render that section. If selser isn't enabled on a wiki then the <references/> tags get auto-added on every edit.

I'm not too bothered if there is a round-trip insertion of a <references/> tag that should've been there, but that should be inserted consistently, and not just when selser is triggered.

Esanders renamed this task from If the user edits an automatic references list, drop the "autoGenerated" attribute so it's serialised rather than ignored to Auto-generated <references /> list can't be moved in VE..Oct 19 2017, 1:54 PM
Esanders added a project: Parsoid.
DLynch added a subscriber: DLynch.EditedOct 19 2017, 2:09 PM

I can see the argument, certainly. I did look at Parsoid's source, and I'm not sure I understand how it's supposed to be handling some of this -- it looks like it only drops the autoGenerated references if it's in a test mode, which is confusing if that's true.

EDIT: oops, missed Ed's second comment.

ssastry added a subscriber: ssastry.EditedOct 19 2017, 2:22 PM

If the references tag never shows up as edited in VE edits, selective serialization sees a zero-offset substring for that <ol> and that serializes to an empty string always.

Non-selective serialization ignores the autoGenerated attribute (except for test mode to eliminate noisiness from our rt-testing setup -- although at some point, we might drop that).

So, it is unclear how to solve this in selser mode ...

If the references tag never shows up as edited in VE edits, selective serialization sees a zero-offset substring for that <ol> and that serializes to an empty string always.

<ol class="mw-references references" typeof="mw:Extension/references" about="#mwt3" data-parsoid='{"dsr":[17,17,0,0]}' data-mw='{"name":"references","attrs":{},"autoGenerated":true}'>..

So, when Parsoid does a page.src.subsring(17,17), what gets emitted is an empty string. The VE patch that forces the serializer to treat the refs tag as modified bypasses selser mode for that <ol> node which is why it works.

So, the situation is that we have a patch which works but is somewhat inelegant, and a proper place to do a fix but we're not sure what that fix would actually be. :D

An inelegant fix is still a fix, and if it makes things better for users then it's got my vote. It can always be replaced with the proper solution later. :-)

If the references tag never shows up as edited in VE edits, selective serialization sees a zero-offset substring for that <ol> and that serializes to an empty string always.
...
So, it is unclear how to solve this in selser mode ...

One option is to use the scrubWikitext mode to normalize auto-generated references tag to a regular references tag which means we will generate a <references /> tag on pages where they were auto-generated before => this will dirty diff *any* page without a <references /> tag on *any* unrelated edit. That is a VE product decision.

Change 384757 merged by jenkins-bot:
[mediawiki/extensions/Cite@master] MWReferencesList: drop autoGenerated attribute if changed

https://gerrit.wikimedia.org/r/384757

Jdforrester-WMF closed this task as Resolved.Nov 7 2017, 10:13 PM
Restricted Application added a project: User-Ryasmeen. · View Herald TranscriptNov 7 2017, 10:13 PM
Elitre added a subscriber: Elitre.Nov 16 2017, 11:27 AM

@Trizek-WMF , couldn't find the task number mentioned in the archived page. If you could drop a note to whoever was interested in this task, that'd be appreciated.

Trizek-WMF updated the task description. (Show Details)Nov 17 2017, 1:52 PM

@Trizek-WMF , couldn't find the task number mentioned in the archived page. If you could drop a note to whoever was interested in this task, that'd be appreciated.

I've updated the task with a more accurate link.

I had seen the thread: still, it seems to be about a different task, so I didn't know which user to ping. But it's OK. Thanks.

My fault, I didn't read carefully your request.
I think ping Drongou and NicoV would be enough if you really wish to inform them.