# VisualEditor/Feedback

This page is a place for you to tell the Wikimedia developers what issues you encounter when using the VisualEditor here on MediaWiki.org. It is still an alpha version and has a number of known issues and missing features. We do welcome your feedback and ideas, especially on some of the user interface decisions we're making and the priorities for adding new functions.

Add a new commentView known bugsReport a new bug in Bugzilla

Archives generated by MiszaBot):

## Clicking edit

When you click edit and the page is blank and then visual editor find a page which was redirected and so you can save the page 5.66.149.62 11:54, 18 May 2013 (UTC)

## VE altered wiki table markup, benignly

I made minor text and link edits to the table in mediawiki.org/Manual:Page_customizations. It worked! I note that VE added whitespace to the opening wiki table markup:

^ This may not even be a low-priority bug, but my understanding is that Parsoid tries not to unnecessarily alter wiki markup. S Page (WMF)(talk) 19:23, 21 May 2013 (UTC)

## allow Enter accelerator in [Review and save]

In old-skool Edit source I'm used to filling in the summary field, tabbing out of it, then pressing Enter to Save page. In VE's [Review and save] > Save your changes dialog, this doesn't work (it's not a form with a submit button, it just looks like one).

Sometimes I'll try to Tab-tab-tab over to the [Save page] button to press Enter on it... that doesn't work either (it's not a form element nor a link and doesn't have a tabindex). S Page (WMF) (talk) 01:27, 22 May 2013 (UTC)

## New paragraphs in wrong order.

I tried to add new paragraphs after the first, but they showed up before, in inverse order. 200.219.132.104 14:39, 22 May 2013 (UTC)

## sdf

sdf 190.121.229.138 19:00, 23 May 2013 (UTC)

Start a new discussion

## Contents

Using up-arrow to scroll to the top of a long article doesn't work023:24, 23 May 2013
Workflow for creating links314:52, 21 May 2013
Installed Latest VisualEditor (12/14/12) but still uses old editor?907:15, 18 May 2013
VisualEditor plus WikiEditor122:30, 14 May 2013
differentiation between editing screen / page viewing801:15, 14 May 2013
Would love to have images and file insert/links on this ASAP115:41, 13 May 2013
Math222:22, 12 May 2013
Really weird bug122:17, 12 May 2013
Surface cover over image link120:04, 12 May 2013
Table editing719:50, 12 May 2013
On Swedish Wikiversity117:47, 9 May 2013
Rapid-fire editing103:15, 9 May 2013
Feedback posting to LQT notice page, not LQT board120:33, 8 May 2013
On the Right Path120:19, 8 May 2013
VE removes normal edit page's active/selected status102:13, 8 May 2013
VisualEditor removed watch status101:30, 8 May 2013
Small Failure100:53, 7 May 2013
text pasted into italic section appears plain400:08, 7 May 2013
 First page Previous page Next page Last page

## Using up-arrow to scroll to the top of a long article doesn't work

Go to some long article (so long that it won't fit on one screen in your browser), start the visual editor, use down-arrow to walk all the way down, then up-arrow to walk all the way back up to the top of the article. It's not possible: the first lines of the article will be obscured by the visual editor's menu bar; the only way to make them visible is using the scroll bar.

23:24, 23 May 2013

I would like some way for <!-- comments --> to appear in the VE.

15:02, 21 May 2013

There are essentially two ways to create a link:

1. You enter the link's text, select it, click the link button, and choose the link target.
2. You click the link button first, enter the target and get out of the dialog, at which point the link text (identical to chosen link target) will be entered.

I'm not sure which method users prefer, but it's clear that both methods should work seamlessly. However, with the current setup both methods are problematic:

1. Once the correct target has been picked (either by entering it, or by selecting from the list), it is not quite clear what the user should do next. Is the back arrow the right thing to do, or does that cancel the selection? Should I simply click outside of the dialog, or does that cancel? It turns out: if the target was selected from the list, both these actions are correct and do not cancel the choice, but if the link target was entered by hand (and not followed by Enter!), both actions do cancel the choice. The fastest way is to enter the link target and hit Enter twice. This is all fairly unintuitive.
2. With this method, the user will often have to adjust the link's text afterwards, for instance in the case of plurals or if the target article is disambiguated with parentheses. But it is not clear to the user that adjusting the link text is safe and won't create a broken link; indeed the whole distinction between link text and link target remains obscure.

I have checked the workflow of entering links in LibreOffice, Gmail and Word; they are all basically the same as in the Visual Editor, with two big differences: the selection box has a clear OK button, and it contains separate clearly labeled boxes for the link text and the link target. I believe both of these changes make a lot of sense.

When entering the dialog from an existing link or from highlighted text, that text should automatically be entered into the link text's box, with a corresponding suggestion for the link target preselected, but both boxes should be editable independently. The link target box should have a list of further suggestions underneath. Once everything is OK, clicking the OK button or hitting Enter should create the link; clicking outside of the dialog box or hitting the back arrow should cancel the action.

There is another minor issue: right now, when hovering over an existing link, the link target is displayed; when clicking on the link, a link symbol occurs which does not show the link target. The meaning of that symbol is not clear; it turns out that clicking on it will allow to change or remove the link. Gmail solves this issue as follows: hovering will not display anything, but when clicking on a link, a tiny window shows up giving the link's target and options to change or remove the link. I find that completely self-explanatory.

21:54, 15 May 2013

All of that makes sense, except “clicking outside of the dialog box”. Closing the dialog and discarding what the user has entered just because some click happened outside of the box would not be user-friendly at all.

00:56, 17 May 2013

I agree with all of this. The current link workflow is really confusing and non-standard, even for experienced users.

03:08, 18 May 2013

Agreed. It's very confusing.

14:52, 21 May 2013

## Installed Latest VisualEditor (12/14/12) but still uses old editor?

I've installed VisualEditor on our wiki, but after enabling it and configuring it according to the instructions I still just see the old editor whenever I create a new page. When I go under Special Pages-->Version I do see that the wiki instance sees the extension. Any idea why it isn't working? Dave

71.185.26.13019:23, 14 December 2012

If the integration has worked correctly, and you have it switched on for your account (if that's how you've configured it for your wiki), on each of the namespaces that you've enabled it on, you should have a new tab labelled "VisualEditor" alongside the "Edit"/"Create" tab.

Assuming that you've installed it correctly, it not appearing is most likely an artefact of you using a browser that fails the current very-restrictive whitelist of what browsers are known to work in VisualEditor (the "big four" of Chrome/Firefox/Safari/Internet Explorer). Note in particular that forks of the big four browsers differ in the ways that we care about, so Iceweasel does not make it through the whitelist. Longer-term we will switch to using a blacklist for known-bad browsers, but we haven't had the opportunity to do this yet.

05:27, 25 February 2013

Blacklist ? Like ten years ago when whith Mac browsers I encountered stupid artificial barriers although my Mac browsers were perfectly able to handle the content ? It would be a bad idea. It would be totally anti-Web.

15:29, 27 March 2013

"Our" ? Who, "we" ?

15:23, 27 March 2013

The time is not modified after I have edited my message. This is a bug. Please fix that. Thank you.

15:33, 27 March 2013

LiquidThreads only puts a notice up if a comment has been edited by another user - you may want to comment on [1].

19:14, 2 April 2013

What is anti-Web is a number of browser manufacturers coming up with their own "variants" on standards that break the concept of one Web for all users, and their failure to work together properly under WHATWG to agree what the standards now should be.

Of course, we would love for VisualEditor to work for all users using all browsers. We certainly intend in the short-term (i.e., in the coming months) to work with all major browsers and make it easy for browser manufacturers and their adherents to see the ways in which their browser fails to meet the standards and so does not work. Longer-term it would be great to expand the number of browsers covered, but due to limited funds and an ever-increasing number of ways that browser manufacturers invent to be incomptabile with each other, that it something that we cannot fund ourselves exclusively.

The world is imperfect, and yet we must live in it.

19:08, 2 April 2013

I have no problem with the Visual Editor not working everywhere — as long as the Visual Editor is done right and respects the standards. There is a problem if the Visual Editor decides not to work in some browser. Check for features, do not check for applications.

16:13, 3 April 2013

That would be a lovely approach to take (and was what we did initially), but then we found that a number of browsers consistently lie about their ability to support features, or have Quixotic support for core JS language elements such that we cannot write code for the standard and expect it to work on them. For example, Android's native browser in version 2 proudly claims that it supports ContentEditable (the key technology for VisualEditor)… but doesn't actually create a user-editable content area (no trigger to give the user a cursor or keyboard).

I entirely understand your antipathy for browser-based whitelisting, but we do not have the resources right now to manually check each browser on the planet and work out whether it is lying to users about the features it supports.

19:25, 3 April 2013

I'm using "Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:21.0) Gecko/20100101 Firefox/21.0" but the Visual Editor tab still does not show although I have enabled it on the settings page. Cinquero (talk) 07:15, 18 May 2013 (UTC)

07:15, 18 May 2013

## VisualEditor plus WikiEditor

You should be able to go back and forth between WikiEditor and VisualEditor until all the features available are identical If VisualEditor isn't going to have a button for creating tables and one for images (and one for wikitext) - I hope this is the plan when released as it would obviate the need for both editors.

22:25, 14 May 2013

I agree that it would be good to allow editors to switch between VisualEditor and the wikitext editor would be good, and we intend to build it, but unfortunately it is unlikely for us to be able to deliver it in the next month or so. Our focus is on providing the ability to add and alter images, references, templates and categories, which we feel are more important than altering the structure of tables. We do not intend to build an "insert wikitext" button, though it's not impossible.

(BTW, the wikitext editor is different from WikiEditor, which is an extension deployed on Wikimedia wikis that gives it a toolbar.)

22:30, 14 May 2013

## differentiation between editing screen / page viewing

Edited by another user.
Last edit: 20:07, 20 April 2013

I find it very difficult to tell at-a-glance when I'm editing with the visualeditor (using alpha on En:wp). With 'normal' editing it's obvious, because the source looks different from the text. In the visual editor, seems like we should change the background color of the edit window -- or a big red banner at the top, or something -- to let you know when you're editing. Otherwise in vector it basically all looks the same, which is confusing.

19:47, 20 April 2013

This is (to some extent) intentional - we don't want "reading" and "editing" to be different modes in people's heads, we want it to be part of the same collaborative continuum. There are ways we can make it a little more obvious without breaking the frame of reference entirely, but overall this is a "feature not bug" kind of thing. :-)

20:10, 20 April 2013

In this case, fine, but the visual editor has to indicate clearly that the content is in unsaved state. The different background is a good idea. But it is not enough, think of colour-blind people and of text browsers. A dot in some title place, à la Mac OS X, is something to do.

18:51, 27 April 2013

When editing I usually have several tabs open on the same wiki. With [Edit source] I can identify the editing tab at a glance as it changes to 'Editing Ti...', but with VE it looks like the other tabs. It would be nice if VE changed the browser tab title when switching modes.

20:10, 8 May 2013

Thanks for the idea - have added it as bug 48272.

20:17, 8 May 2013

I find the editing tab too thanks to its specific title. It would be too bad to break this habit.

14:17, 12 May 2013

We don't want you to break your habit; we want your habit to transfer to using VisualEditor. :-)

More generally, a lot of our work over years has been around guiding people to use the "Edit" tab; the entire point of becoming the "default editor" is to be the place new users will click into to edit, without needing to know that they want to click "VisualEditor" rather than "Edit" (or whatever).

19:57, 12 May 2013

Aah, “tab” ! I did not speak of the tab in Wikipedia. I speak of the tab in my Web browser. That is the HTML title of the page. For example, in “Editing Wikipedia:Sandbox - Wikipedia”, the word “Editing” at the beginning is important.

15:21, 13 May 2013

## Would love to have images and file insert/links on this ASAP

Would love to have images and file insert/links on this ASAP

152.160.16.9815:41, 13 May 2013

Agreed; we're working on this and hope to have it available in a few weeks.

15:41, 13 May 2013

## Math

Is there any work in supporting mathematical equation ([itex]) editing? It should be possible, since Microsoft Equation Editor and OpenOffice Math both have it.

23:19, 25 April 2013

I don't believe there's any active work on it but that would be very interesting.

If someone's thinking of diving in, you might look into what people are already working on with math editors related to the MathJax client-side rendering. I don't know if there's something fully working yet, but it might be nice not to have to start from scratch. :)

15:00, 27 April 2013

We've decided that [itex] elements aren't as high-priority as references and templates, but it's definitely something I want to happen.

Just because two well-established tools with multi-billion-dollar companies behind them can been able to produce a visual equation editor doesn't mean it's "easy", but I think it's worth doing. :-)

There is a Google Summer of Code student who's hoping to build a visual equation editor for VisualEditor if you're interested in progress

22:22, 12 May 2013

## Really weird bug

That "pawn" bug (bugzilla:48346) must be one of the weirdest bugs I've ever seen. Here's another strange one, seen in Firefox 20.0.1:

1. Go to w:Mersin İdmanyurdu SK and invoke VisualEditor
2. The cursor should automatically be on the first (blank) line. Start typing
3. As well as a appearance of a pawn, strange duplication of characters starts to occur

Not only is VE playing chess, but perhaps also some drinking games :)

10:41, 11 May 2013

Yes, this is the same bug; I think we've fixed these problems in master (which means it will be fixed here tomorrow, and on enwiki next week), but we'll verify.

22:17, 12 May 2013

## Surface cover over image link

Try the visual editor on https://www.mediawiki.org/wiki/User:Dantman/Code_Ideas and scroll down to the image.

iirc that's supposed to be an image link, not an image. And in VE the entire thing isn't covered on hover making it still a link.

19:49, 12 May 2013

Oh dear, that's an unfortunate bug in Parsoid; filed as bug 48387. Thanks for the report.

20:04, 12 May 2013

## Table editing

It says in the minutes of 27th March under things that won't work:

• Tables

But will already existing tables (done through mediawiki syntax) be able to be edited in the release planned for 1st July? It seems to work fine in the test sandbox. This is something that would be very useful for us since we sometimes have large tables edited by several users. This work can be very tedious using wiki syntax.

/Daniel

195.60.68.15513:11, 12 April 2013

Editing the contents of existing tables' cells will work, but you won't be able to alter the structure (add/remove columns/rows, merge cells, set background/etc. formatting).

17:57, 18 April 2013

How in any way is this acceptable? You're saying that an editor who wants to do anything with a table other than edit a cell has to switch to Vector to do so? At what point in the future do you think that Visual Editor will be able to edit everything related to a table - a few months after July 2013? A year or two? In the meantime, will you be recommending to new editors that they abstain from any more complicated table editing, or that they learn Vector as well as VisualEditor in order to have the full range of editing options?

04:44, 3 May 2013

I think that it's totally appropriate for projects that are primarily based on text, templates, images and references to have an editor which can do those well, rather than poorly with additional support for very complex tables that are currently outwith the capacity of editors familiar with wikitext, let alone newbies. The VisualEditor in no way makes it harder to edit a table than it currently is (quite the reverse). Yes, more progress would be nice, and so would a unicorn, but we have to work within reality.

We will focus on a table editor after the beta is launched, but I can't make up a date of it being ready at this stage as we aren't sure what facilities users will definitely need from such a tool (obviously add/remove row, column, cell; merge cells; mark cell(s) as 'header'/'footer'/'body'; add/remove caption - but there are other things that users might want to do as well, and I'm not going to declare it "done" when we've only hit those four functionalities.

Also, you mean "wikitext", not Vector, which is a skin. :-)

15:46, 3 May 2013

Sorry, apparently I misunderstood - the first production version (July?), not the beta (April/May?), will be able to do more than just edit existing cells in a table. That's fine.

19:49, 7 May 2013

The alpha is the currently-deployed opt-in. The beta will be the default editor for all users. "Final" version will likely be some way off, and will include such things as editing table structures and so on.

01:31, 8 May 2013

## On Swedish Wikiversity

Hi!

I have quite a few teachers who are eager to share their knowledge on Wikiversity here in Sweden. I think they would be very glad to be able to use the Visual Editor rather than the syntax. Would it be possible to have it on the Swedish Wikiversity as well as it would help them greatly?

17:15, 29 April 2013

Hi there (sorry for the delay in replying),

I don't think we currently have support in VisualEditor/Parsoid for Wikiversity sites. We've done absolutely no work on non-Wikipedia workflows, tools and extensions, and I'd be worried that we'd either break the site (unlikely, but not impossible) or be utterly useless, and we wouldn't have the time to help fix it in a useful fashion. Sorry! In a couple of months we should review our support for non-Wikipedia wikis and start the discussion about how well we can support your particular needs from VisualEditor, ahead of wider roll-out for everyone.

17:47, 9 May 2013

## Rapid-fire editing

I edited a page with VE and saved successfully. I immediately opened the VE again, but the page I was given to edit did not have my most recent change. This seems to happen whenever I edit twice within a few seconds.

00:01, 9 May 2013

Sorry about this bug; we've fixed it in master but it's not yet deployed - it will be here on MediaWiki.org on 13 May and more widely soon afterwards.

03:15, 9 May 2013

## Feedback posting to LQT notice page, not LQT board

I'm not sure why my feedback ^above^ from VE got inserted up here. I copied and pasted my feedback from a text editor into the VE [Leave feedback] dialog, it looked fine there and I got a confirmation from VE.

20:32, 8 May 2013

This is because we're using the core MediaWiki feedback tool, and LiquidThreads doesn't extend the API that the core tool uses, just captures section=new events through the UI. See bugzilla:41276. It's annoying, but not enough to switch off the tool.

20:33, 8 May 2013

Trying to make a local link to a section,

• The link pop-up dialog doesn't offer any help
• In wiki markup I know to type a leading #, when I start typing #Something the dialog displays
 New page
[checkmark] #Severity (in red)
Matching page:
\$1


The resulting link to a section works, but the dialog is misleading.

20:31, 8 May 2013

## On the Right Path

I just finished reading Karen McGrane's recent column on A List Apart in which she discusses the separation of content from presentation. It made me think of the work around VisualEditor and, in my humble opinion, a reaffirmation that you're on the right track.

http://alistapart.com/column/wysiwtf

15:57, 8 May 2013

Thank you! I agree with the value in the split, and we're keen to focus on tools that help our editors create content rather than endlessly fiddle with presentation (though tools for setting CSS/etc. will be forthcoming).

20:19, 8 May 2013

## VE removes normal edit page's active/selected status

When you are on the normal edit page and VE replaces the edit button with an "Edit source" button it removes the selected/active styles from it.

02:12, 8 May 2013

Yes, sorry, this is now fixed in master and will be deployed in the new branch (wmf4) released here on 13 May.

02:13, 8 May 2013

## VisualEditor removed watch status

I edited a page that was on my watch list with the VisualEditor. When submitting it the "Watch this page" was unchecked and when I just saved as normal VE removed the watched status of the page.

((There's a small possibility that I actually clicked the watch star and then opened up the VisualEditor after that instead of reloading first))

01:29, 8 May 2013

Hey, this is odd behaviour indeed. Do you know what browser you were using at the time?

01:30, 8 May 2013

## Small Failure

During the edition with the visual editor, an unwanted modification happened: ></table http://es.wikipedia.org/w/index.php?title=Alcatraz_%28serie_de_televisi%C3%B3n%29&diff=66703778&oldid=66536861

The prior disordered the table. Supousedly tables can not be edited, but this one was :)--3BRBS border|20px @ 16:31 6 may 2013 (UTC)

16:34, 6 May 2013

Thank you for your feedback! Sorry about this bug - we discovered it last week. It's due to a jQuery bug that we encountered with new code, which is now fixed in "master" ([1], [2]) and will be made available in production for eswiki on Wednesday 8 May.

Table structures aren't editable (no adding columns or rows), but cell contents should be - if you have any problems, please report back! :-)

00:53, 7 May 2013

## text pasted into italic section appears plain

Select a single word of text in some other app, paste it into an italic block in the editor, and the italics are closed and reopened either side. This is in Firefox 20 on Linux using the keyboard.

15:23, 4 May 2013

Yes, all copy-paste from external sources are stripped of all formatting before insertion; we're fixing this in 33105. I'm not sure we'd also want to provide a "paste without formatting and inherit local styles" tool, as this will be a mess to provide.

15:27, 4 May 2013

A mess ?? But this is the standard behaviour in any word processor software. I don't speak here of pasting formatted text. But, when there is plain text in the clipboard, pasting it must do the same as typing the same text with the keyboard — that is : give it the local formatting.

18:22, 6 May 2013

Yes, but giving users three options:

• Paste with remote formatting
• Paste with local formatting
• Paste with no formatting

... feels like a mess.

22:09, 6 May 2013

The choice would be between “original formatting” and “local formatting”. “No formatting” would not be an option. But, anyway, this does not apply to plain text in the clipboard. When there is plain text to paste, there is no choice, the text simply has to be pasted, without interfering with formatting.

00:08, 7 May 2013

 First page Previous page Next page Last page