Apr 4 2018
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...
Apr 2 2018
Mar 24 2018
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.
Mar 14 2018
Mar 10 2018
Have just been playing around with this - looks great.
Mar 3 2018
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.
Feb 28 2018
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.
Feb 24 2018
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.
Feb 19 2018
Feb 17 2018
Feb 13 2018
Feb 12 2018
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.
Feb 6 2018
Feb 3 2018
Jan 29 2018
These aren't quite duplicates.
Nov 17 2017
Oct 22 2017
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:
Oct 17 2017
Oct 15 2017
Sep 5 2017
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.
Aug 29 2017
@Whatamidoing-WMF Should the feedback link go here? https://www.mediawiki.org/wiki/Talk:VisualEditor/Diffs
Aug 15 2017
Correction: this isn't specific to historical diffs
Aug 11 2017
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.
Aug 10 2017
Oops, should've tagged: rGVED81a4760ea38c: VisualDiff: Refactor for historical diffs
Jul 31 2017
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.
Jul 24 2017
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...
Jul 18 2017
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?
Jul 15 2017
Sorry, I meant any template that isn't visible when just reading the article.
Jul 11 2017
Jul 10 2017
@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.
Jun 26 2017
Is this good to close now?
May 17 2017
Yeah that's the culprit
@Mooeypoo No worries, I'll look into it - thanks for the pointers.
May 16 2017
May 9 2017
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?
Mar 29 2017
Mar 22 2017
Mar 17 2017
Mar 14 2017
I'm having trouble replicating this - has it been fixed?
Feb 23 2017
Feb 21 2017
Feb 19 2017
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...
Jan 25 2017
The above commit addresses step 1 but not step 2 yet.
Jan 24 2017
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!
Jan 14 2017
Jan 11 2017
Jan 10 2017
This was caused by deciding a content branch node with content length 0 was modified to an alien node.
Dec 12 2016
@ssastry The version that relies on HTML-based serialization hasn't been deployed yet, but there have been some recent changes around the prefixes.
Yes - very happy to do that
Dec 3 2016
I think this is because the space in the gallery dialog is narrower. After playing around a bit, setting a smaller row height seems to increase the probability of the images fitting better...
It would be less confusing if the gallery dialog disabled height, width, etc in the modes that they don't apply to.
There is a slightly complicated reason for this...