Page MenuHomePhabricator

VisualEditor: Mis-nested annotations are cleaned up, leading to a dirty diff
Closed, ResolvedPublic

Description

...and quite dramatically - take a look at https://en.wikipedia.org/w/index.php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133


Version: unspecified
Severity: normal
See Also:
T50830

Details

Reference
bz50052

Event Timeline

bzimport raised the priority of this task from to High.Nov 22 2014, 1:54 AM
bzimport set Reference to bz50052.

Brad also has a suggestion (along with a bug report) for a workflow to make these easier to identify:

"One way to catch this for debugging purposes would be for the VisualEditor to make a note at tuntime of which sections of the article have been edited visually, for the JS code to report this to the server at save time, and then to check on the server side which sections of the article have changed in the wikitext diff. If (a) the section structure of the article remains unchanged from before the edit, and (b) there are wikitext differences in sections that have not been changed by the editor in visual mode, then something's clearly gone wrong, and the edit session should be auto-reported to the programming team. (Please don't try to use this idea as an error concealment technique: these errors shouldn't occur, as every one of them reveals some sort of bug, either in the code or the data model, and hiding them would make the software more, rather than less brittle.)"

(In reply to comment #0)

...and quite dramatically - take a look at
https://en.wikipedia.org/w/index.
php?title=Modified_discrete_cosine_transform&diff=561051085&oldid=558725133

Eurgh. I hate being proven wrong; each of those changes fixes the (entirely-broken, but masked for users by MediaWiki) wikitext; these are the kinds of errors it's not really possible for us to re-implement.

Specifically, <i>Foo <sup>Bar</i> Baz</sup> is definitely broken HTML (mis-nested annotations), and I don't think it's necessarily a bad thing that we fix these. Obviously it'd be much better if we had a bot do a massive run over the corpus and fix these for users now, rather than have them blame VE, but that's not going to happen. :-(

Punting to Roan for thoughts, but I think this is probably a lost cause.

(In reply to comment #1)

Brad also has a suggestion (along with a bug report) for a workflow to make
these easier to identify:

That's going to be done in VisualEditor as part of bug 49761 (well, not that way, because VE can't objectively know what bits of the DOM it "should" have just altered unless we have a local copy of MediaWiki :-)) but yes, coming very soon, hopefully.

Jdforrester-WMF lowered the priority of this task from High to Medium.Jan 15 2015, 12:35 AM
Jdforrester-WMF set Security to None.
matmarex subscribed.

Parsoid's "selective serialization" has been improved greatly since 2013 and this should not be occurring any more, unless content in the same paragraph was changed in the edit. Please re-open if you run into similar dirty diffs that happened within the last year or so.