data-mw.i seems to be dropped on edit in latest VE, which causes a loss of round-trip information for spaces etc.
Version: unspecified
Severity: major
Description
Description
Details
Details
- Reference
- bz51150
| Subject | Repo | Branch | Lines +/- | |
|---|---|---|---|---|
| Remove workaround for Visual Editor bug (T53150). | mediawiki/services/parsoid | master | +0 -6 |
Related Objects
Related Objects
Event Timeline
Comment Actions
This then causes diffs like http://en.wikipedia.org/w/index.php?title=Bj%C3%B6rk&diff=563745216&oldid=563123196
Comment Actions
I can't reproduce this, even if I edit the template. VE preserves unmodified data-mw attributes always.
Also, what is data-mw.i ? Is it new?
Comment Actions
https://en.wikipedia.org/w/index.php?title=Christchurch,_Dorset&diff=prev&oldid=563716751 appears to be a pre-deployment occurrence.
Comment Actions
It is either data-mw.i or data-mw.parts[<n>].i for templates. It is not new, but so far we have not used that information that heavily, so the fact that you drop the i probably fell under the radar. We use it to associate the public entry with private round-trip information such as the order of parameters and (crucially for this bug) whitespace.
echo -e '{{echo|a = foo\n|b = c}}| node parse
<body><p about="#mwt1" typeof="mw:Transclusion" data-mw='{"target":{"wt":"echo","href":"./Template:Echo"},"params":{"a":{"wt":"foo"},"b":{"wt":"c"}},"i":0}' data-parsoid='{"dsr":[0,27,null,null],"src":"{{echo|a = foo\n|b = c}}","pi":[[{"k":"a","spc":[""," "," ","\n"]},{"k":"b","spc":[""," "," ",""]}]]}'>{{{1}}}</p>
</body>
Comment Actions
(In reply to comment #4)
https://en.wikipedia.org/w/index.php?title=Christchurch,
_Dorset&diff=prev&oldid=563716751
appears to be a pre-deployment occurrence.
This is post-Parsoid deployment.
Comment Actions
Example on http://www.mediawiki.org/wiki/User:GWicke/TestDataMW?veaction=edit:
Original data-mw:
data-mw='{"target":{"wt":"echo","href":"../Template:Echo"},"params":{"1":{"wt":"foo"}},"i":0}'
data-mw through VE without edit:
data-mw="{"target":{"wt":"echo","href":"../Template:Echo"},"params":{"1":{"wt":"foo"}},"i":0}"
data-mw through VE after changing 'foo' to 'bar':
data-mw="{"target":{"wt":"echo","href":"../Template:Echo"},"params":{"1":{"wt":"bar"}}}"
Note that the "i" member is gone.
Comment Actions
The Parsoid workaround above is now deployed. If the index went missing in VE, it assumes that a single-transclusion target was not swapped out and reinserts the lost index in that case. This should avoid corruptions in the common single-template case.
It will do nothing for multi-transclusion content (table start / row etc), and will also fail if the template was swapped out for another one. The latter case should be rare.
Comment Actions
Change 73372 had a related patch set uploaded by Catrope:
Preserve unused Parsoid template properties
Comment Actions
I'm assuming that this is not yet deployed, as a new report was added to 51161:
This is what happened:
http://en.wikipedia.org/w/index.php?title=Scarborough_railway_station&diff=next&oldid=557856562
This is what the user intended:
http://en.wikipedia.org/w/index.php?title=Scarborough_railway_station&diff=564074475&oldid=557856562
If removal of newlines really is necessary, please insert a space instead. If
that is not possible, please remove the spaces from both sides of each equals.
An arrangement like
| name = Scarborough | symbol = rail | code = SCA | image_name = |
ScarboroughRailwayStation.jpg|caption = The entrance to the station
gives the impression of associating a parameter name with the value immediately
preceding. An arrangement like
| name=Scarborough | symbol=rail | code=SCA |
| image_name=ScarboroughRailwayStation.jpg | caption=The entrance to the station | |
would associate a parameter name with the value immediately following.
Normally this single-transclusion content should be covered by the Parsoid workaround. Did anything change in the VE handling recently that could have re-added the "i" property with a faulty value?
Comment Actions
(In reply to comment #15)
I'm assuming that this is not yet deployed, as a new report was added to
51161:
It is deployed.
Normally this single-transclusion content should be covered by the Parsoid
workaround. Did anything change in the VE handling recently that could have
re-added the "i" property with a faulty value?
That sounds unlikely. When the user adds a new parameter, that parameter won't have an i value, but that seems reasonable to me.
I'll try to reproduce this later and see what's being sent back to Parsoid.
Comment Actions
(In reply to comment #16)
(In reply to comment #15)
I'm assuming that this is not yet deployed, as a new report was added to
51161:It is deployed.
Normally this single-transclusion content should be covered by the Parsoid
workaround. Did anything change in the VE handling recently that could have
re-added the "i" property with a faulty value?That sounds unlikely. When the user adds a new parameter, that parameter
won't
have an i value, but that seems reasonable to me.
That infobox already existed. The 'i' property is per transclusion, not per parameter.
Comment Actions
We've not seen this recur; it was probably caused by mis-cached code. Closing, but please re-open if it does happen again.
Comment Actions
Change 180240 had a related patch set uploaded (by Cscott):
Remove workaround for Visual Editor bug (T53150).
Comment Actions
Change 180240 merged by jenkins-bot:
Remove workaround for Visual Editor bug (T53150).