This behaviour is caused by the CSS fix to T170114, which preserves whitespace in removed/inserted content, so we can see removed/inserted spaces properly. There's a slight inconsistency in this fix: whitespace is collapsed if content is unchanged, and preserved if content is changed.

I agree, that might be the thing to do here... We could even start by always having that message (and not calculating/showing any metadata diffs), while we figure out how best to display this kind of thing in the visual diff.

In T199298#4420683, @Esanders wrote:

so ideally we would just fix the placement of that comment node (which might be more in @dchan 's ball park)

It already is giving us a CommentMetaItem... Sounds like it's related to T189543

This looks the same as T187589 and is probably due to something in the diff-patch-match library which does the linear diffs.

The reason I put it here is because the work I'm doing on lists diffs happens to solve this too, but happy to move it if that makes more sense...

Indeed, not ideal. The reason we see this message in the diff is because we happen to be building it as a visual editor document, and this is the message that visual editor displays - there is no separate message just for the diff. We could make the message more generic so it would make sense in both the editing and diffing contexts.

In T186672#4041550, @Samwilson wrote:

That's a good idea. I've switched it to do so; see what you think.

Have just been playing around with this - looks great.

In T187613#4000508, @Schnark wrote:

On the other hand, even if something isn't editable visually, you could still show it in diffs. If it changed in some way, put the old version into del, and the new into ins, and the diff will be correct

In this particular case, the problem is caused by the diff timing out, at which point it just gives up and says everything in the old version was removed and everything in the new version was inserted... Once T180842 is fixed, we will at least show a message to explain that this has happened.

Hmm, the task is phrased a bit strangely. We don't actually have custom messages for adding/removing/changing content for references - we just show the change.

Thanks for this, I've seen other examples like it.

The fact that it isn't showing the blockquote diff is a separate issue. It seems blockquotes aren't even editable in visual editor, so it makes sense that the in-editor diff doesn't handle them.

In the example given, a lot of the time was spent putting the visual diff document html together. The problem is, we make the html from the visual editor linear data, and given the way that works, <del> and <ins> have to be added as annotations to each character, so when we are dealing with several hundred paragraphs, all inserted or deleted in their entirety, this takes a long time. One way round this is to bypass the normal visual editor converter when making html for the diff document, so we can add those tags directly.

These aren't quite duplicates.

Looks like it's because these are timing out at the tree diff stage, because of the long bullet lists. We should do two things:

Ah it's because the reference name="bd-pratidin.com" is defined more than once in the page - so editing anything but the first one won't make a difference.

I don't think it's because there aren't visible changes on the page - the model of the page has still changed as far as the visual diff is concerned. I'm having trouble reproducing this behaviour locally, so I suspect it is not a visual diff problem.

I think I'd still be concerned about crowding the diff if the origin is highlighted, even if only a small excerpt is shown (see @Pginer-WMF's example C above)... But maybe we'd have to balance how common/bad this would be compared to how much there is to gain from knowing exactly where the origin was.

@Whatamidoing-WMF Should the feedback link go here? https://www.mediawiki.org/wiki/Talk:VisualEditor/Diffs

Correction: this isn't specific to historical diffs

In T170235#3448693, @Esanders wrote:

Just to be clear, this behaviour should not be happening and should go away once T170269 is fixed.

That does @Deskana's suggestion but not @matmarex's...

Has this been resolved now?

Interesting. This is another one of those cases (like historical reference diffs) where we rely on the assumption that the diff is between a document and some changes to it that have just been made in visual editor.

Oops, should've tagged: rGVED81a4760ea38c: VisualDiff: Refactor for historical diffs

In T169325#3477128, @Schnark wrote:
I'm wondering whether it is really necessary that the diff tells you exactly where each of the paragraphs moved.

I'm wondering the same thing. I agree that it's nice to know exactly what happened for a simple move, but that for anything more complicated it's probably more useful just to be aware that some moves have happened.

I'm not sure the moved content should be shown twice in its entirety - it could make the diff quite complicated in cases where multiple paragraphs or whole sections are moved, or where multiple moves are made...

This was fixed by https://gerrit.wikimedia.org/r/#/c/355716/ - the preview now matches the editor.

I just tried reproducing both of these examples, but looks like it's fixed now?

Sorry, I meant any template that isn't visible when just reading the article.

@Esanders Do you have any ideas about "columns setting changed"?

This is a bit more complicated than it looks - we don't have a way yet of describing changes for a newly inserted/deleted node - only changes to an existing node. We should think about other cases that this would apply to (e.g. invisible templates) and come up with a general solution.

Is this good to close now?

Yeah that's the culprit

@Mooeypoo No worries, I'll look into it - thanks for the pointers.

I'm having trouble replicating this, even when I search for "Sandbox". It could be that it's an odd case and the results have changed since... Is it still happening?

I'm having trouble replicating this - has it been fixed?

Some thoughts:

The first example is fixed by correcting a few indices, but the second poses a more philosophical question about minimal-tree-diffing 2D matrices, so requires a bit more thinking...

The above commit addresses step 1 but not step 2 yet.

We also need to display node type changes. The boundary between the two is not always obvious in VE (e.g. <p> to <h1> is a type change, but <h1> to <h2> is an attribute change), so we should treat these as the same problem.

Yes, I'd like this to be user-oriented too!