Jump to navigation Jump to search

About this board

Post your feedback about using the visual editor.

If you have never provided feedback before, you can learn how to do it effectively. If you are reporting a problem directly on this page, please include your web browser, computer operating system, and wiki skin (usually Vector, sometimes Monobook). The feedback tool within the visual editor will include your user agent details instead.

You can use this page to tell the Wikimedia developers your ideas and issues about using the visual editor: this is the only feedback page actively monitored by WMF staff. The Contributors team welcomes your feedback and ideas, especially on user interface decisions and the priorities for adding new features. All comments are read, in any language, but personal replies are not guaranteed: the team will try and go through reports here at least once a week. Need more attention? Report directly in Phabricator. Please note that the Wikimedia Foundation does not provide support for installing VisualEditor on third-party wikis. Please report bugs involving Parsoid at Talk:Parsoid instead.

You may also want to read a guide to optimize the visual editor's experience on your site, which details work necessary on the community side (such as translating or setting up citation systems).

View open developer tasks Report a new bug in Phabricator Join the IRC channel Test the visual editor! (no account required)

Bug (regression): VisualEditor forces piped-link creation

Summary by Jdforrester (WMF)

Follow up on phab:T219023.

SUM1 (talkcontribs)

Since about a week ago, VisualEditor forces the creation of piped links when using the built-in hyperlink feature, even if the text is the same as the link.

Before, linking "five-year survival rate" or "short bowel syndrome" would result in "[[five-year survival rate]]" or "[[short bowel syndrome]]".

Now, it results in "[[Five-year survival rate|five-year survival rate]]" and "[[Short bowel syndrome|short bowel syndrome]]" every time.

Please fix.

Browser: Chrome 72.0.3626.121

OS: Windows 7 64-bit

Skin: Vector (default)

SUM1 (talkcontribs)

Only just realised that this issue extends to the source editor too, but I am unable to delete this post.

SUM1 (talkcontribs)
Jdforrester (WMF) (talkcontribs)

Hi there. Thanks for filing the task; let's follow-up there.

Visual Editor as default editor?

AmplifyWiki (talkcontribs)

Is it possible to set it so when you go to edit a page on Wikipedia, Visual is the default choice rather than Source?

Jdforrester (WMF) (talkcontribs)

Yes, on some wikis. On the English Wikipedia, in your preferences set "Always give my visual editor if possible".

This applies to other wikis which have "Single Edit Tab" mode available, which is not all of them yet. I'm not sure what the team's plans for deploying that are.

AmplifyWiki (talkcontribs)

Thank you for that. When I clicked the link I was able to uncheck "Temporarily disable the visual editor while it is in beta", which served the same use. And then when I clicked edit on a page it prompted me to pick a default editor. Thanks again!

Data loss during entry while using VE

WikimeSteve (talkcontribs)

We are experiencing lost data during entry when some heavy users are working with VisualEditor. I only have this level of detail for one event. Here is our server info

Product Version

MediaWiki        1.31.0

PHP      7.2.9 (cgi-fcgi)

MySQL  5.7.23-log

ICU       62.1

VisualEditor 0.1.0 (13a585a) 15:14, 30 May 2018

The behavior is not easily or reliably reproducible. When it occurs it is described as a surprise. We have 3 -4 reasonably solid reports of it since last November 2018 with the most recent last Monday 3/4/2019. A few other common traits to point out. The users were mostly working with a table on a single page. Mostly working on the unique page alone. Always making many changes and saves to the page. The work might have extended out over several days. In at least once case it was done from a laptop that was turned off in the evening though the browser may have been left open.

The most recent goes like this. User was working on a table which has 550+ rows and 3 columns. Nothing fancy beyond hyperlinks in some cells. It is a glossary list though not setup for Lingo extension use. On Friday 3/1/2019 more than 65 Saves were made to the page. 18 by person A then 3 by person B then 8 by person A then 1 by Person B and the rest to the end of that day by Person A. Reviewing all of these Saves everything works fine. There are Additions and a few intentional deletions to the list in all cases and nothing anomalous.

Monday 3/4/2019 Person A starts working on the same page where they left off from the same laptop. According to the time stamp on the compare history view this occurs at:

Revision as of 09:34, 4 March 2019 The right-hand side (under that date stamp) of the page show 5 rows with content were added. Clicking to move to the next page the left-hand panel (under that same date stamp) in yellow shows all the exact same content that had + signs, here shows them with a – sign in front.

Revision as of 09:39, 4 March 2019 The right-hand panel shows 7 rows with content in the fields being added and the next page shows all the exact same content that had + signs here showing with a – sign in front.

Revision as of 09:42, 4 March 2019 The right-hand panel shows 1 row with content being added and the clicking to go to the next page shows all the exact same content that had + signs here showing with a – sign in front.

Revision as of 09:43, 4 March 2019 The right-hand panel shows 1 row with content being added and the clicking to go to the next page shows all the exact same content that had + signs here showing with a – sign in front.

There are 7 more entries like this before it all stops.

At this point the user looks at the actual table and sees that none of their additions or edits are present. The user experience so far had been identical to Friday. Edits made, Save button in Visual Editor turned blue. Clicked it when ready. Progress completed. Page came back for more editing. No negative messaging. The user fully expected the work to be present as it was on Friday. A second round of trying to make these edits takes place with the same result. The issue is reported to the rest of the Wiki Admin team. By the time Person A gets back to try again Person B has successfully made a Source View Edit (first time that day). The issue does not repeat for Person A now and their work can be completed.

Attempting to purposely create a new row adding content to all 3 cells, then deleting the row does allow then clicking Save does not reproduce the effect. Viewing history shows no entry since nothing was actually changed. So, our 11 occurrences do not appear to be something that can be done manually.

I see nothing in the history mentioning “Rollback” on these items though the behavior seems much like a rollback occurred a the same moment it was saved.

One user who reported this experience did say they were not in a table when it happened.

Most users were in Edge though one reporting using Chrome and experiencing it.

Whatamidoing (WMF) (talkcontribs)

Could there have been an edit conflict, due to more than one person editing the same page at the same time?

WikimeSteve (talkcontribs)

Double checked that in each case at the time and it would not have been happening. Thanks

Reply to "Data loss during entry while using VE"
Alzi24 (talkcontribs)

When browsing through the various documentation pages, it seems as if development has been suspended two years ago. Sorry for the maybe silly question, but what is the current status of the VE? Are there plans for relaunching and further development? Or am I completely wrong and the VE is alive and healthy, just the documentation a little bit outdated?

AKlapper (WMF) (talkcontribs)

What exactly makes you think that development has been suspended? :) Documentation updates are welcome if you find something outdated!

Alzi24 (talkcontribs)

It's just what I am worrying about when viewing ...

and so on. It is all a little bit difficult to understand for s.o. outside the WMF and/or developer team.

I might be completely wrong - alright then, the better. We are just a small private wiki and have installed the VE (which is "still experimental" for outside Wikimedia, as I read) to launch for a usability test. I would not appreciate investing time in testing and asking for support, if I'll hear it will be ceased afterwards. On the other hand, outdated pages might be a manpower bottleneck just the same as with our contributors ...

Finally, the Talk pages consultation 2019 and look to me as if there were bigger problems the WMF has to deal with, than some minor VE bugs and requests.

Jdforrester (WMF) (talkcontribs)

VE (which is "still experimental" for outside Wikimedia, as I read)

Correct. The Foundation's budget priorities don't align with us making the epic re-engineering of VE into a state that it's as easy to install as the rest of the MediaWiki, and so it would be irresponsible for us to recommend it to low-end third party users.

Note that there's no-one who is paid by the Foundation to provide support to anyone for any part of MediaWiki, core or extensions, let alone VE. The support that do people get is generally either staff working in their personal time, or other members of our wonderful developer community, both volunteers and those paid by other organisations.

To help the team out, I have updated the three old status systems to explain to people that the are obsolete , noted that there aren't any VE-specific engineering update systems any more , and removed the reference to when the 2017 editor's integration last changed . Thanks for spotting the issues, and sorry it caused you concern!

Reply to "Current project status?"

VisualEditor won't finish loading

4 (talkcontribs)

Here's a screenshot about what's happening everytime I try to create or edit a page. The blue bar appears, load until ~70% then freeze.

I tried to check what's happening with firefox & chrome dev tools. Everything seems fine, here's a sample of a request json response.

{"visualeditor":{"result":"success","notices":["<p>You have followed a link to a page that does not exist yet.\nTo create the page, start typing in the box below (see the <a class=\"external text\" href=\"\">help page</a> for more info).\nIf you are here by mistake, click your browser's <strong>back</strong> button.\n</p>"],"checkboxes":{"watch":"<input name=\"wpWatchthis\" type=\"checkbox\" value=\"1\" tabindex=\"1\" accesskey=\"w\" id=\"wpWatchthis\" />&#160;<label for='wpWatchthis' id='mw-editpage-watch' title=\"Add this page to your watchlist [w]\">Watch this page</label>"},"links":{"missing":["Cpage"],"extant":[]},"protectedClasses":"","basetimestamp":"20150813153540","starttimestamp":"20150813153541","oldid":0,"content":""}}

It's like he doesn't try to load the next page, the form for page edition / creation.

It's a private wiki. MediaWiki's 1.25.2. I got VisualEditor-REL1_25-c947b49.tar.gz and UniversalLanguageSelector-REL1_25-7661826.tar.gz. Here is my conf

### UniversalLanguageSelector (prérequis Parsoid)     # wfLoadExtension( 'UniversalLanguageSelector' );     require_once "$IP/extensions/UniversalLanguageSelector/UniversalLanguageSelector.php";     $wgULSGeoService = false;     $wgULSEnable = false;     $wgULSIMEEnabled = false;

    ### VisualEditor     wfLoadExtension( 'VisualEditor' );     # require_once "$IP/extensions/VisualEditor/VisualEditor.php";

    $wgVisualEditorSupportedSkins = array( 'Vector', 'Apex', 'Monobook', 'Minerva' );

    # Enable by default for everybody     $wgDefaultUserOptions['visualeditor-enable'] = 1;

    # Don't allow users to disable it     # $wgHiddenPrefs[] = 'visualeditor-enable';

    # OPTIONAL: Enable VisualEditor's experimental code features     #$wgDefaultUserOptions['visualeditor-enable-experimental'] = 1;

    # URL to the Parsoid instance     # MUST NOT end in a slash due to Parsoid bug     $wgVisualEditorParsoidURL = 'http://localhost:8000';     $wgVisualEditorParsoidHTTPProxy = false;

    # Interwiki prefix to pass to the Parsoid instance     # Parsoid will be called as $url/$prefix/$pagename     $wgVisualEditorParsoidPrefix = 'wikidiff';

    # # Namespaces for VE     #$wgVisualEditorNamespaces = array_merge($wgContentNamespaces, array( NS_USER ));     $wgVisualEditorNamespaces = $wgContentNamespaces;

    # Timeout for HTTP requests to Parsoid in seconds, and for serializationcachetimeout     $wgVisualEditorParsoidTimeout = 200;     $wgVisualEditorSerializationCacheTimeout = 3600;

    # Réglage parsoid pour wiki privé     #     $wgSessionsInObjectCache = true;     $wgVisualEditorParsoidForwardCookies = true;

Anyone can tell me what the hell is wrong ? It's been two long days...

Winand (talkcontribs)

Did you resolve that issue somehow? When I turn on $wgResourceLoaderDebug VisualEditor loads. But without debug mode it freezes at 70%.

Jeroen N (talkcontribs)

This is happening to me more and more, to the point I've had to disable the visual editor altogether. The same goes for the 2017 wikitext editor. (talkcontribs)

I have the same problem. Without $wgResourceLoaderDebug it freeze by 70%. For testing, i disabled all other plugins. but it dosn't solve my problem. Any idea someone?

Reply to "VisualEditor won't finish loading"

Erreur à l'utilisation "no vrs"

Titanscity (talkcontribs)


J'utilise Firefox 52 sur Windows 10 et mon mediawiki est en monobook (

J'ai installé visual editor et modifier le fichier localsettings.php mais lors de la modification d'une page, la barre de chargement bleue apparait, commence à se remplir puis j'ai un message d'erreur :

Erreur lors du chargement des données du serveur : no_vrs: The VirtualRESTService for the document server is not defined; see Voulez-vous réessayer ?

Mon médiawiki est installé sur une serveur mutualisé. J'ai cru comprendre qu'il fallait d'autres installations ? J'avoue que l'installation de cette extension est un vrai casse-tête et l'expérience utilisateur est détestable :D ce n'est pas à la portée de tout le monde d'en faire l'installation a priori !

Est-ce que quelqu'un *lance une bouteille à la mer* saurait m'aider pour configurer/utiliser l'éditeur visuel ?

Merci d'avance !


Whatamidoing (WMF) (talkcontribs)

I'm sorry; I don't know how to install this. Perhaps you would like to post at Project:Support desk?

Zer00CooL (talkcontribs)

Tu as de nouvelles informations depuis ? Je cherche également.

Reply to "Erreur à l'utilisation "no vrs""

Standalone (possibly desktop) version

Dzmitry.lahoda (talkcontribs)

I have found that demo in source code can load local files, but stores in browser storage. Could demo application store as file (replace original)?

Could VisualEditor be packages as Electron application? May be it is already packaged? I want to use it as HTML visual editor.

Matma Rex (talkcontribs)

It probably could be, although I don't think we tried it. The demo in the browser can't store files on your filesystem, but an Electron application could.

Look at minimal.html and demo.minimal.js for better examples if you're trying to integrate VisualEditor into another application. The default demo includes a lot of debugging features that you probably don't want.

Dzmitry.lahoda (talkcontribs)
Reply to "Standalone (possibly desktop) version"
Frlara (talkcontribs)

How can I add a line break from VE? I tried shift-enter and all other key combinations, but it always starts a new paragraph. I also didn't find it in the toolbar. (talkcontribs)

you can add a line-break by shift-enter, but after the cursor you should have some character.

Reply to "Line breaks"

IPv6 problems with VisualEditor loading?

The Anome (talkcontribs)

I've noticed that when using the new, non-forms based editor (in either the source or full WYSIWYG variants), the "progress bar" at the start of the editing process will often get stuck about 75% of the way through, preventing the page from being edited, but that this behavior happens only when I have IPv6 connectivity enabled. Without IPv6 enabled, this is never a problem. With IPv6, it happens most of the time; page reloads will sometimes fix it, but it may take a lot of them to do so. I suspect this might be an IPv6 connectivity problem with some of the servers in the Wikipedia hosting cloud.

(Note: this is using Firefox 65.0.1 on MacOS Mojave 10.14.3.)

The Anome (talkcontribs)

Update: en:User:Izno has reported a very similar experience on enwiki: .

Matma Rex (talkcontribs)

Sounds similar to the loading failure reported in T213214. No one connected it to IPv6 before though. Can you check if you get the same error in browser console as mentioned on that task?

The Anome (talkcontribs)

I've managed to reproduce the problem again, with IPv6 enabled. The exact error I'm getting in my browser error console is:

Loading failed for the <script> with source “”

However, fetching the script from the URL above manually succeeded immediately, so I can't track the problem down any further at the moment.

What I would note, though, is that URL is 2364 characters long, well over the 2000 character limit that is generally regarded as safe across all browser platforms. And the payload ia an amazing 600 kbytes long!

One more data point: pinging what appears to be ipv6 endpoint: 2620:0:862:ed1a::1 for a minute or so shows zero packet loss.

The Anome (talkcontribs)

Update: I've been able to provoke the same problem again, connecting via IPv6 as before, and it chokes in the same place: loading the huge script with the very long URL.

The Anome (talkcontribs)

@Whatamidoing (WMF) A question: are the servers/load balancers/caches/network paths exactly the same for both IPv4 and IPv6 traffic? If not, it's possible that the choice of protocol is simply routing the traffic to parts of the infrastructure that have problems not directly related to the protocol itself (such as, for example, out-of-memory problems).

Whatamidoing (WMF) (talkcontribs)

I'm not entirely sure who to ask. @BBlack (WMF), which team would you recommend for this question?

Reply to "IPv6 problems with VisualEditor loading?"
Alzi24 (talkcontribs)
Software 	Version
MediaWiki 	1.31.1
PHP 	7.2.15-0ubuntu0.18.04.1 (apache2handler)
MySQL 	5.7.25-0ubuntu0.18.04.2-log

We have installed the VE for a trial now. Within its help menu, the first item is "Read manual". It links to

Mw:Special:MyLanguage/Help:VisualEditor/User guide

which is empty. How can I support our users with a reasonable VE help?

Whatamidoing (WMF) (talkcontribs)

You can copy that user guide to your wiki, and update the link.

Alzi24 (talkcontribs)

Copy which user guide from where?

And: copying means - I will have to check everyday if there are changes made to that manual and if yes, I will have to copy it again?

Totally stumped. This is the year 2019 and you are suggesting me methods like previous century.

Whatamidoing (WMF) (talkcontribs)
Alzi24 (talkcontribs)

It's a little bit strange, but ... I think I'll create the page and fill it with a link to the user guide. Then I'll wait and see how the reactions are.

Alzi24 (talkcontribs)
Alzi24 (talkcontribs)

By the way, the newly created page "Mw:Special:MyLanguage/Help:VisualEditor/User guide" is a page in the main namespace as "Mw" is not a valid namespace. It is all a big mystery to me ...

Whatamidoing (WMF) (talkcontribs)

"Mw" is an interwiki link to Special:MyLanguage helps route people to the language they set as preferred (if any) in their account (otherwise, English).

Alzi24 (talkcontribs)

Ok, that's new to me. I have to learn a bit more ...

Alzi24 (talkcontribs)

Got it, finally. I installed the "Interwiki" extension, created the "Mw" entry (which has to be flagged as "local interwiki", whyever) and then the VE redirects me to the german users guide. It was a little bit difficult to figure out how it works, but that's exactly what I have been looking for. No manual linking, no copying required.

This is of course not last century, thousand pardons for that.

Reply to "VE help shows empty page"