VisualEditor/Feedback
This page is a place for you to tell the Wikimedia developers what issues you encounter when using 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 comment – View known bugs – Report a new bug in Bugzilla – Join the IRC chan
Archives generated by MiszaBot):[edit | edit source]
Would be great to allow navigating via keyboard only, if I would not be forced to use the mouse for certain actions.
E.g. when having the cursor in a wikilink, I'd like to press tab, then that "edit link" icon should be focused, pressign enter should then open the edit dialog there and focus the input box.
Being forced to use the mouse for editing is annoying since everything takes more time. 93.220.106.148 17:07, 6 September 2013 (UTC)
Contents
 First page |
 Previous page |
 Next page |
 Last page |
I have installed the latest Visual editor extension from GIT master on my local wiki. I get the new More group menu with four items Media, Reference, Reference List, Transclusion, but I cannot see the other new controls for underline, subscript etc. Am I not suppose to see them as I do on the mediawiki site?
Also it would be very nice if the editor buttons would be configurable in some way. I mean that you configure the ones you use the most to not be contained in a group/menu. For example we use strikethrough quite a lot which would be a bit difficult to reach on a menu. But I guess there will be keyboard shortcuts and that could be a solution too.
/Daniel
For now, the whole title will be wrapped by nowiki tag, as which may break other thing, such as conversion on zh.wikipedia.
Instead of using nowiki tag, as a talk in Wikimania2013, it is recommend to use a space between the title-tag(==) and char-to-be-shown(=), like == =a= ==.
Hello, a minor, but nevertheless a little confusing feature is that when we open an article for editing, red links appear to be blue. Also, when adding a new red link, it appears to be blue. After saving, of course you can see it is red, but I think this is confusing for newbies, why they see a red link when selecting it from the search popup and then it suddenly turns blue and when they save the article it is red again. :) The tool should keep the original color of the link. Cheers.
Hi Teemeah, we are working on this issue at Bug 37901. Thanks for your report.
Hi! I am so far pleased with the progress of the editor but right now it is not really capable of handling images well. Instering images into tables is almost impossible with the tool. I tried it at huwiki with a large table that contains one image per row. The tool inserts the image with a pre-set -thumb- code, and it is impossible to get rid of it, the tool only offers adding a caption and no other possibilities. This seriously hinders continuous work, as I would have to add the photos manually in wikicode, separately because there is no way of switching back and forth between VE and wikitext editor without losing what I was doing. Before full deployment, image and table handling needs to be fixed, otherwise VE will be virtually useless for experienced editors.
The other thing is that handling citation templates is currently a nuisance in VE. each and every parameter has to be loaded manually, in a separate window, and if you want to add another parameter, you have to click back to the main tab and start again, + add the content of the parameter separately. This means that adding one parameter approx. uses up half a minute + a lot of extra clicks and loading time. The VE should be capable of loading the full parameter list of a template in a single window, so you can fill them in quickly. I would not use this tool to fill in an infobox at the moment. Takes horribly long!
Kind regards,
When I write long articles in VisualEditor the whole screen scolls - and the VisualEditor toolbar is scrolling upward and out of the screen. If I want to make a headline or instert a picture I'll have to scroll up to the top to reach the toolbar. I've tried it in the lastest edition of Firefox and Chrome in Win8 - on my own mediawiki with visualeditor and Wikipedia and Mediawiki. What am I missing? I assume that it is not supposed to be like this?
Odin
Hi MyOnlyEye. I've been doing some testing to reproduce this issue on en.wiki with different browsers and OS. Could you give me an example article where this is happening?
On every page that is longer than the screen - e.g. http://en.wikipedia.org/wiki/Electron?veaction=edit
I've tested a bit (after I wrote the feedback) and it seems to be OK on my Win7 and Linux-box (chrome and firefox, both in 64-bit), but it's not working on Win8 (32-bit). Both the lastest 32-bit edition of Chrome and Firefox have the "scrolling error" on my Acer W510 Win8-laptop in desktop-mode (and in tile-mode :-). I will try to test if it has something to do with the driver for the screen or if it's a win8 thing.
Would you mind trying it again? This week's update was supposed to fix some toolbar-related problems. If it's still broken (or, worse, if it's now broken in places where it used to work correctly), then please let us know.
Nope - no change :-( I tried the electron-article and updated my own wiki (with git pull on mediawiki developer and visualeditor).
I tried it in Firefox and Chrome (latest 32-bits editions).
Does https://bugzilla.wikimedia.org/show_bug.cgi?id=52504 sound like the same problem to you?
Pretty often i come across visual edits where users misapplied the heading format to obtain a boldface type, obviously both as vandalism and unintentionally. In these cases the table of contents contains the text of a whole section. It is clear that there is no way to avoid this generally, but I think a warning would be useful, if the heading size exceeds a preselected number of characters or if the heading contains a linebreak.
One of the things we want to bring in is showing the Table of Contents with live updating, so that it's clear when users add a heading. This should make abuse of headings a bit more obvious, hopefully.
The length of headings might be a separate concern, though (as part of a wider set of possible stylistics suggestions).
Hi there, I am here to report a bug, I think :) Yesterday I created this sandbox, and although after doing so I could tell from the URL that I should have seen a pop-up confirming this operation, it only actually appeared when I hit Edit to modify the page. This should go elsewhere, I know, but I wrote it here in the meantime so I won't just forget. Thanks.
Hi,
Will there be options for the image alignment in visual editor? Now it seems to default to right so you need to go into edit source mode if you want to change this.
Thanks for the great work.
Thank you.
We're planning on building image location setting, yes; right now it defaults to right (in LTR environments) or left (in RTL environments) and you can't change it, but when this is built (in a month or two) you will be able to set it as you like (left/right/centre/in-line), as well as other settings (like type - frameless/framed/thumb, (vertical) alignment, etc.).
I noticed that the search function in the Insert Media dialog is limited to image titles only. For Example, if an image has an english title and explained in English and Arabic in the description, it will not show up in the media dialog if i used Arabic phrases to search for it. Even if those phrases 100% match the Arabic description of that image. What needs to be done in to extend the search function to cover all the text of an image page. Then we can call all contributors to try and add description in their native language for as many media files as they can.
This does not seem to always be how it works. The Commons database is slow to notice changes for searching (sometimes two or three days). Which image were you searching for? Had you recently added the picture or the Arabic translation?
yes you'r right. Images start to show up now. But I was wondering is there a way to add keywords to the images for better search results? Perhaps a template in an image page serving that purpose?
You shouldn't need to do anything extra. If you put "silly rabbit" into the search box in VisualEditor's image box, then you ought to get exactly the same results as putting "silly rabbit" into the search box at Commons. At least, that's what happens when I do it, and "silly rabbit" isn't in the title of any of the files.
Looks great everyone, some suggestions:
A medium sized thumbnail preview inside the dialog box when editing the image caption/properties would be a nice touch. Sometimes you just want to look at what you're writing about!
A simple button to insert the occasional wikitext code would be great. Or will extensions be able to add a button to the interface? The simple video extension Wikia created works great on my wiki but an 'Insert Video' button would eliminate the need to switch to wikitext.
A preview of the item inside the media dialog is planned, yes (right now we have no options for inline files, but this will change soon).
All MediaWiki extensions that add features will be able to register themselves to add a button to the toolbar (or more complex behaviour); documentation coming soon.
Any update on IE support?
Sorry if this is the wrong place to ask!
As an extension, are there settings to enable it for ANY browser and play with it? Our school would like to experiment with it, but the whole board is locked into IE 8 (Maybe 9 if a miracle has happened over the summer).
On that note, if part of the goal is to draw in more female editors, I would suggest that many of those women would be my colleagues, teachers. Again, we're all locked into the school board's IE8 configuration, and many at home will be running windows IE 8 at home for at least while.
I feel like the editor is geared partially to those people who will say "Google made a web browser?" So IE should be a priority. :)
Internet Explorer support is tracked from bug 50085. There are a number of relatively-minor issues, and one complete show-stopper: bug 49187 - Internet Explorer's security model means that the cross-server requests used to save the page don't work, so users can never save their work. We plan to build a work-around this model, but for now it means VisualEditor is unusable on Internet Explorer.
Note that our intent is to provide support for IE9 and above; IE8 fails to support many of the key technologies used in VisualEditor, so supporting it would require us to create a forked version of VisualEditor just for IE8, which is not something we can justify.
Visual Editor create a new kind of weird vandalism, and very often is not with bad intentions. Before, vandalism consist in a person wich, in strange ocasions, write several words or delete something, now there is people changing formats and introducing codes and there is more people writing unusefull words only because it's only necesary a clic and you can write. Look at this, and this. In the time with Visual Editor we don't have seen any improvement in the march of Wikipedia, so the question is "why we get it?". I think that it's not and was not necesary and make easier vandalism and unusefull editions and make that the vandalism in the articles appears more often because it's easier.
Hi Carlos. The problems you have observed are concerning, and we are looking at solutions. The "nowiki" issue happens when editors use markup characters (double brackets, consecutive equals signs, etc.) We have put a warning in place to reduce the number of these instances, and are looking at other long-term solutions. I know this is not ideal, but I would point out that the wikitext editor also results in good faith formatting errors as well - there is a learning curve with both systems. As for the total quality of VE edits on the whole, the data so far has shown no major difference in the quality of VisualEditor edits versus wikitext edits.
Hi, is it a desired behaviour that adding more than one linebreak leads to one line break?
e.g. When I hit three times return, after saving the page, I get only one return.
Im on the master branch commit 2c4e9d832374f095d3fa9d43b845ac7c7083aeb4 Merge: c84c47a 7673a39 Author: jenkins-bot <[email protected]> Date: Wed Aug 14 22:00:12 2013 +0000
I work mainly on the gv.wiki and have just started a discussion there about the rollout. As a very small wiki we don't keep much abreast of changes like this. I'm waiting to hear from other users, but given the amount of concern about Visual Editor bugs I've seen on various discussion pages, I am not keen for it to be rolled out for us at this stage. There are very few editors, so anything that might increase the error rate (both for experienced editors and visitors) is a concern. In the future it seems like a promising option to encourage our very small speaker pool to contribute, but until the concerns about bugs have been dealt with we may want it delayed. It's possible that other very small wikis may feel the same?
The next major update (about a week from now) is expected to deal with a lot of the existing problems, and some of the complaints you're reading about have already been solved or at least improved. The only Manx-specific concern that I'd have is with diacritics, since some users don't know how to make those with their own computer.
Have you tried it yet? You can test it at gv:Er_lheh:Preferences#mw-prefsection-editing (assuming you aren't using Internet Explorer or some other blacklisted web browser). Keep in mind that it works more like a word processing document, so you type Control+k or ⌘ Command+k rather than [[square brackets]] to make a link. Help:VisualEditor/User guide is not very long, and it is worth reading.
Thanks, my concern isn't so much about actual use of the VE (which is editors' individual problem), but reports that it was corrupting, mis-saving, and otherwise accidentally affecting pages, as we wouldn't necessarily notice these and they would eat up editors' time. If this can be solved then it's probably okay. I've had a look at VE and have used similar interfaces before, so that's not a concern.
Shimmin Beg - the two bugs that would likely cause cleanup work are the "nowiki" issue (where VE places nowiki tags around wikitext markup when accidentally used in VE mode) and the table corruption bug, where tables with incomplete markup are handled poorly by VE. The first will hopefully be improved by a rollout next week, and the second is being worked on. As the table issue is only happening rarely on a big wikis like en., I don't forsee it happening often (or at all) on the Manx wiki. Does Manx have a large number of table templates?
There are two main types of nowiki errors. One adds a completely pointless nowiki tag, and this is irritating and wrong, but doesn't actually need to be fixed. (It's something that you can see in the diffs—we call them "dirty diffs" because it adds unnecessary junk to the diff—but not in the article.) The other is the addition of nowiki tags around square brackets. This has been very common at the English Wikipedia (less so, now that typing them triggers a warning), but has not been seen at all at some of the smaller Wikipedias.
Good to know. I don't think we have much in the way of table templates, so it sounds like it should not be a major problem. Thank you both for the clarifications.
I just discover bugzilla a few hours ago. I am a newbie on bugzilla and I don't know to write a bug here so well , my english grammar is not perfect so for this I so apologise and any suggestions to this bugs/ideas somewhere else , or any help is welcome an appreciated . This is my list of ideas /bugs : 1. I am wikipedia reader for many years and just today I have found bugzilla.wikimedia.org . So many times I have I was frustrated and I wanted to write a few suggestions but was to complicating using editing tools ( the new visual editing seems a big step further ) or it was about the content it was about the software (wikimedia) and the browser - Chrome that was something wrong . So in my humble opinion , the bugzilla.wikimedia.org should appear in front page of wikipedia.org because is very important but I belive ( maybe I am wrong) that no so many people new about the existence of bugzilla.wikimedia.org . They are many websites that have like a user opinion , (see kick ass torrent-idea box), suggestions , feedback so on , little box on the front page , or at the botton toghether with other wikimedia projects , on every article page ,together with editing option of course.In this way the development , bug repporting will be much faster , more quicker , in my humbele opinion . I think that this bugzilla.wikimedia.org is too complicate for a non-technical guy in comparation with IdeaBox And Feature Requests from http://kickass.to/ideabox/ , and hard too find , I just stumble upon bugzilla.wikimedia.org ,is not so very visible . All right , you can compare wikipedia 500 milions readers, no 5 website with kick ass torretns but I think we can learn something from them , from others . In my case I wanted to say something,to report a bug , to help a little but I din't want to become a programmer , a coder. And I was thinking that MediaWiki.org is for technical people , for development software team not for me,not for end -user. 2. When you want to print article like this http://en.wikipedia.org/wiki/Liver using google chorme browser (most widely used web browser in the world ) , Internet explorer browser , Mozilla firefox browser , the colors that appear here at
Artery hepatic artery Vein Hepatic vein and hepatic portal vein Nerve Celiac ganglia and vagus nerve[1] Precursor Foregut MeSH Liver
Hello Zenhabit and thank you for your message.
You are not actually on Bugzilla. You are on Mediawiki. Mediawiki is an easier place to post suggestions than Bugzilla, although you have to find a page about the feature you're interested in. But the easiest place is to post suggestions at the w:Wikipedia:Village Pump of your favorite Wikipedia. In your case, since your edits are mostly at the English Wikipedia, the best place for suggestions is at en:Wikipedia:Village pump (technical). Several software developers read it, and other people there can help you with your ideas. Good luck!
Hello.
I noticed that if I try to insert a new link on a text, and the text is located in the lowest part of the screen, the pop up window appears below the visibile area and, consequently, is not visible (unless you scroll down the browser bar, of course). For usability reasons the displaying should be fluid (and flexible): if there is not enough space below, the pop up should appear above (or elsewhere).
It is an important issue, because the user should be always put in a position to understand what is happening. :)
Could someone please help me by reporting this issue in Bugzilla. I have been tried to register since a couple of days but I don't receive any confirmation email... Thanks!
Lucas, sorry for the late reply. I have filed your request as a new bug: Bug 52526.
When I click "edit" on some pages, I get an error message from Firefox:
A script on this page may be busy, or it may have stopped responding. You can stop the script now, or you can continue to see if the script will complete.
If I click "Continue", the message returns after a few seconds. The error is reproducible on en:List of popes.
I'm running Firefox 22.0 on Win7.
There are a couple of parameters which should nearly always be added to an image in an article: alt for accessibility, and of course a caption. The user would experience a better work flow, and be reminded about alt which is often forgotten, if the image insertion dialog transitioned to the image parameter editing dialog (only caption at present, others to follow with bug 38129) when an image had been selected instead of back to the article.
78, I have added this request to Bug 38129. I agree it is important.
If I double-click a wikilink to select it and then press the italic button, the code generated is [ [Cliché|' 'Cliché' '] ] instead of the more idiomatic ' '[ [Cliché] ]' ' (see this diff). This use of double-click and the GUI button is pretty instinctive: I think the editor needs to support the expected behaviour.
First page |
Previous page |
Next page |
Last page |
