Page MenuHomePhabricator

Move visual diff out of beta in visual and 2017 wikitext editors
Closed, ResolvedPublic0 Estimated Story Points


It would be great to move this out of beta and make it the default diff tool in the visual editor.

It seems to me that quite a few of the remaining tasks (e.g. T170134, T167510, T161489, T160588, etc) are currently blocked on design decisions - e.g. do we keep the sidebar? do we display items such as comments that you wouldn't see in read mode? etc.

There is a detailed discussion happening on T169325, some of which we have already acted on (e.g. improving the way moves are calculated).

But what are the next steps, in terms of making decisions? Perhaps we should prioritise doing the design research outlined in T171456 based on the current state, then go forward in light of what is found.

Event Timeline

The important question is "Is this a minimum viable product?" For this product, that translates to "Is this better than the wikitext diff?" That question will be answered by the evaluative research that is being performed by @dchen in T171456 et al.

I don't think we need to have every design question fully resolved to move forward with graduating out of beta if the evaluative research has a good outcome. @Tchanders will continue to work on visual diffs, and she can work on those design questions in the next iteration.

Are there other issues that may be blockers?

Deskana set the point value for this task to 0.Oct 20 2017, 3:36 PM
Deskana moved this task from To Triage to TR6: Visual diffs on the VisualEditor board.

Change 404660 had a related patch set uploaded (by Esanders; owner: Esanders):
[mediawiki/extensions/VisualEditor@master] Make visual diffs the default in visual mode

Deskana renamed this task from Move visual diff out of beta in editor to Move visual diff out of beta in visual and 2017 wikitext editors.Jan 17 2018, 12:46 PM

Here's some additional context I evidently forgot to add:

  1. @dchen did some evaluative research which showed users have a preference for the visual diff layout and that it better helps them understand their changes. The research is documented on
  2. Visual diffs will only be moved out of beta in the visual and 2017 wikitext editors. Visual diffs remain unavailable in the 2010 wikitext editor, so the older wikitext diffs system will remain the default for that editor.
  3. Per T178691, the user's previous choice of diff mode will be remembered automatically from edit to edit, so if a user prefers one diff mode over the other then that users will be presented with that diff mode by default.

This would be good to go in to tech news.

There's no train next week, so I'll get it in the edition of tech news that's going out in the week of 5th February.

Change 404660 merged by jenkins-bot:
[mediawiki/extensions/VisualEditor@master] Make visual diffs the default in visual mode

An item about this has been added to – feel free to make sure there are no mistakes or misunderstandings.

When I saw Visual Diff was coming our of beta and made default in Visual mode, I tried testing it. The very first test blew up on two different computers.

  1. To test a large diff and to quickly test a variety of diffing-behavior, I grabbed the wikitext for one article and pasted it into another article and diffed without saving. (i.e. Pasting United States into Zaire).
  2. View wikitext diff worked promptly and perfectly.
  3. I clicked Visual diff. The browser completely froze up. I couldn't click anything. The browser was locked up for more than 5 minutes. I seriously did not want to lose the other tabs I had open, so I left the computer hoping it would eventually unfreeze. (This is when I began the test on a second computer.) When I returned an hour later I was able to close the tab and rescue my existing tabs. (Whew, relief.)
  4. On the second computer I tried the same thing. Clicking Visual diff didn't lock the browser this time, but the individual tab chocked for a minute and a half before doing anything.
  5. When the Visual diff did "load", the top of a visual-diff was visible. However trying to scroll was almost 100% broken.
  6. The CPU-core was pegged at overload, even when I let it run for 40 minutes it was still overloaded and scrolling was still almost completely broken. (Dual-core pegged at over 50%.)
  7. At that point I tried clicking the link at the bottom of the diff for reporting a problem. A new tab opened for a Flow post, however the Flow page was broken. Apparently the diff-javascript so overloaded the system that the javascript in the new-tab Flow either didn't fully load or was unable to fully execute.
  8. I closed the the non-working tabs on both computers. I didn't attempt to test what size diff it takes to kill the system.

I think we need an emergency block on moving visual diff out of beta. It would be bad enough that the diff itself was broken, but locking up one browser, and overloading the other so badly that it broke other tabs is not remotely acceptable.

P.S. The computers were Windows 7 and Windows 8. One browser was the latest release of Firefox, the other browser was a year old Firefox variant.

I understand that your report is that when a user pastes in a huge, complex article into another one, the user’s browser can lock up. I tested this and could not reproduce this issue on my system, and the visual diff displayed fine. Our testing of the visual diff system showed it is performant in a wide variety of circumstances. Regardless, I filed a task to track performance improvements in this area. I also filed a task to investigate the old diff system, since when a developer tested your report, the visual diff worked fine but the old diff caused his browser to freeze.