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

bzimport added a project: VisualEditor-DataModel.Via ConduitNov 22 2014, 1:54 AM
bzimport set Reference to bz50052.
Ironholds created this task.Via LegacyJun 23 2013, 1:55 PM
Ironholds added a comment.Via ConduitJun 23 2013, 2:03 PM

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.)"

Jdforrester-WMF added a comment.Via ConduitJun 23 2013, 3:19 PM

(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 moved this task to Backlog on the VisualEditor workboard.Via WebNov 24 2014, 1:22 AM
Ironholds removed a subscriber: Ironholds.Via WebDec 5 2014, 3:19 PM
Jdforrester-WMF lowered the priority of this task from "High" to "Normal".Via WebJan 15 2015, 12:35 AM
Jdforrester-WMF set Security to None.

Add Comment

Column Prototype
This is a very early prototype of a persistent column. It is not expected to work yet, and leaving it open will activate other new features which will break things. Press "\" (backslash) on your keyboard to close it now.