Wikipedia:VisualEditor/Feedback

From Wikipedia, the free encyclopedia
Jump to: navigation, search
Share your feedback
Report bugs
Your feedback about VisualEditor

Use this page to tell the Wikimedia developers your ideas and issues about using VisualEditor. All comments are read, but personal replies are not guaranteed.

Feedback

Please click here to report a problem with VisualEditor.
Please include your web browser, computer operating system, and Wikipedia skin (usually Vector, sometimes Monobook).
Please click here to make a suggestion.
Ideas about user interface choices and the priorities for adding new features are especially welcome.


Other ways to contact the team More


Help Local archives
The following WMF employee is active on this page:

Screen repositioning[edit]

I have previously reported this, but it seems to be getting worse and worse. Increasingly clicking on anything on the VE Toolbar results in a repositioning of the article back to the first screen (although it seems to be random, or at least I am not seeing the pattern). It is making it very hard to use the VE on any article of non-trivial size, because if you are working in the middle of it and it suddenly takes you to the top, it's a real pain to try to find your way back to the section where you are working. At least when it was only happening at the bottom of the article, it was easy to just drag the scroll bar to the bottom to get back, but finding your way back to something in-between is much more time consuming. Kerry (talk) 02:38, 5 May 2017 (UTC)

I'm not seeing anything like this on Phabricator, I think. Does it happen while you're logged out or using the new safemode trick, that allows us to understand whether a script/tool is interfering? (While VEditing, add &safemode=1 to the URL and reload.) If it does, then provide browser (+version), operating system, and skin, please. Also LMK what's an article where I can reliably reproduce this. TYVM, Elitre (WMF) (talk) 09:56, 5 May 2017 (UTC)
Originally reported here [1] where I included a diff and in a following comment I pointed to the same problem occurring in the middle of the article. Others found it reproducible. I was logged-in. I have not enabled/disabled any safe mode by any explicit action of mine. Why is it not in phabricator? Nobody tells me why they ignore my bug reports. I don't believe it is a long-standing bug. I add commons categories a lot to the bottom of articles without problem, until the problem starting occurring a day or two before I first reported it, so I think it's something that crept in during that time frame. As I said then, the VE still knows where my cursor is positioned (the action selected on the toolbar will occur in the correct place), but my screen is displaying the top of the article. Kerry (talk) 23:30, 5 May 2017 (UTC)
I may have simply failed in searching on Phab of course (if there was a bug that meant every Chrome user was consistently getting screen jumps, I think we would have heard way more about this, as we're getting almost 1M of VEdits per month). When I asked "Does it happen while you're logged out or using the new safemode trick, that allows us to understand whether a script/tool is interfering?", I was asking you to try whether any of those actions made a difference, because I can't reproduce this (I should add I have Chrome Version 58.0.3029.96 (64-bit)/Win 10 though). Whenever you have a bug that others can reproduce, I encourage you to throw it into Phabricator: I simply copy/pasted your words at https://phabricator.wikimedia.org/T164720 . --Elitre (WMF) (talk) 09:23, 8 May 2017 (UTC)
I am using Version 58.0.3029.96 of Chrome on Windows 8.1. Here is a concrete example, open The Old Windmill, Brisbane in VE (I've been working on it for the last couple of days and it's been driving me crazy), and scroll down to the heading Tourist Attraction, then click on the link National Trust of Queensland OR click on the first citation at the end of the first para. Both will zap you straight to the top of the article. Do it as the first action you do after opening the file for edit (the first action almost always does it), after that it seems to be more random. It often happens if you add a paragraph at the end of the article too. What happens when I log out? Nothing of course, because the VE is not available to IPs. What happens when I add the safe mode to the end of URL? No change, I repeated the experiment described above, and sure enough it zaps to the start of the article on that first attempt to click on the citation or the link. Kerry (talk) 10:03, 9 May 2017 (UTC)
It could be that the OS makes a difference after all, as it still doesn't happen for me. (FWIW, of course you can use the visual editor while you're logged out. You can reach it both by changing the URL to &veaction=edit, or to just switching via the button on the toolbar.) I hope the team manages to reproduce and understand what's wrong there. best, Elitre (WMF) (talk) 10:12, 9 May 2017 (UTC)

Removing one copy of a note destroyed the note text[edit]

Bug report VisualEditor
Description Removing one copy of a note destroyed the note text
Intention: Remove a note that appeared in multiple locations from one of those locations
Steps to Reproduce: Diff
Results: The other instances of the note lost the text of the note.
Expectations: The text should have been moved to one of the other instances.
Page where the issue occurs
Web browser Chrome 58.0.3029.96 (64-bit)
Operating system Windows 7
Skin Vector
Notes:
Workaround or suggested solution Manually move the note text to another instance first.

Mike Christie (talk - contribs - library) 10:58, 5 May 2017 (UTC)

1. There is no issue, just a hack doing hacky things ... 2. The "{{#tag" is a hack that is being heavily abused in that article. 2. The expectation here would simply raise more problems , because <ref> tag was not designed to be nested in a <ref>even in pure wikitext. 3. It does work as expected when the hack is not used. 4. The only reasonable (and unpopular) solution here is deprecating and killing the "{{#tag" parser function. — Preceding unsigned comment added by 197.218.82.97 (talk) 18:39, 14 May 2017 (UTC)

No preview button or list of templates[edit]

User agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.96 Safari/537.36

URL: https://en.wikipedia.org/wiki/Lawrenceville,_Georgia?veaction=editsource&section=3#Climate

 Supuhstar *  17:12, 7 May 2017 (UTC)

@Supuhstar: FYI, the list of templates is available from the drop down menu on the top right as "Templates used". —TheDJ (talkcontribs) 12:01, 8 May 2017 (UTC)

Text disappeared during editing, when I tried to drag wording down the page[edit]

Browser

OS version -->

Bug report VisualEditor
Description text disappeared, then froze when I tried to change to source editing
Intention: I was trying to drag a paragraph down the page
Steps to Reproduce: What did you do? Describe how to reproduce the problem, so another person could follow your steps:
  1. First highlighted the text to move
  2. Then dragged it to the position I wanted it to go
  3. Finally when the text above that section disappeared, I hoped I might get it back by switching to source editing

Please mention if it's reproduceable/if you attempted to reproduce or not.

Results: tried to do the same with Ohaupo railway station and had no problem dragging text, or then switching to source editing
Expectations: Can I recover the edit which has frozen?
Page where the issue occurs https://en.wikipedia.org/wiki/Huntly_Railway_Station
Web browser Chrome Version 57.0.2987.133 (64-bit)
Operating system Mac OS Sierra 10.12.4 (16E195)
Skin
Notes: screenshot -
whilst changing to source editing
Workaround or suggested solution to copy remaining text from screenshot and rewrite the rest

Johnragla (talk) 02:40, 15 May 2017 (UTC)

Page options in Visual Editor[edit]

New users can easily reach the Categories, Page settings and Advanced settings screens, where many will experiment without understanding the effects of their actions or whether they are helpful or appropriate. Important parts of the issue have been raised before here.

In Categories new users will add non-existent categories or add their user page to mainspace categories, which is deprecated per categorization guideline.

In Page settings they can:

  • Redirect the page – many will try to redirect their user page to a non-existent mainspace article or to an external website; and set the STATICREDIRECT magic word.
  • Add the FORCETOC and NOEDITSECTION magic words, including to pages with no sections.
  • Categorize the page as a Disambiguation page.

In Advanced settings they can:

  • Set the INDEX or NOINDEX magic words. Trying to control indexing like this has no effect in most namespaces (see WP:Controlling search engine indexing). In user space it overrides the default no-index setting, which most new users have no valid reason to want to do.
  • Set the NEWSECTIONLINK or NONEWSECTIONLINK magic words.
  • Add the DISPLAYTITLE magic word – this is intended to stylize the existing title, but many will input a completely different title, which is ignored by the software.

Thus many of the controls on these screens encourage new users to take actions that either have no effect, have unwanted or incorrect effects, or are against Wikipedia policy or practice. The harms of allowing easy access to these controls to inexperienced editors are debated in more detail in the earlier discussion linked above. If it is urged that VE should reproduce all facilities offered in wikitext editing, in the case of magic words there is no comparison: in contrast to VE, none of the wikitext editing controls link to magic words, and before discovering magic words most editors would formerly have acquired considerable experience and be likely to use them appropriately.

New incidences of one of the magic words are listed here. It will be noticed that nearly all new users listed there have also changed several of the other settings listed, to no benefit to themselves or Wikipedia. I urge redesign of VE page options to point users more towards a basic set of controls that are likely to be useful to most of them: Noyster (talk), 21:27, 15 May 2017 (UTC)

Firstly, not all VE users are new editors; I'm certainly not, so don't take away my tools. New users using the wiki-text editor break things every day too, because they don't understand wikitext syntax and so they screw up articles by trying to edit them and removing the trailing ref tag on citations or add fields to infoboxes that aren't supported by the template type or turn a table into a pile of rubble. I deal with this stuff on my watchlist every day as IPs are using wikitext (indeed, one of my main uses for the wikitext editor is to clean up wikitext syntax accidents). New editors in wikitext makes syntax errors. Because VE users can't create syntax errors (well, they can but it's much harder for them), their errors will tend to be semantic errors. The underlying problem is that new users are new; they can do damage no matter what tool is at their disposal, just the type of damage changes depending on the tool. Having said all that, with VE, we *could* restrict some of the more advanced features to new users. Maybe we could make doing an "online tutorial with quiz" a pre-requisite to enable each advanced feature (gamify it even, e.g. "Category achievement unlocked!"). With wikitext we have no ability to prevent new users from breaking anything and no real way to insert a "learning opportunity" into the process. So I think in the long run, we are actually much better off with new users in VE than in wikitext, as we do have a growth path into a supported learning framework. Kerry (talk) 06:57, 16 May 2017 (UTC)
+1, this is a non-issue. Those, more advanced, options are hidden away in a menu most new users are unlikely to ever click. I've been using VE for a while now and I've never clicked it before now. Sam Walton (talk) 09:38, 16 May 2017 (UTC)
I feel the same as Kerry Raymond and Samwalton9 - I'm not a new editor, but have found its tools actively beneficial to my workflow (especially the options, which I only recently discovered). I have noticed that the options menu seems to pop up more frequently (e.g. if I'm creating a redirect and switch to VisualEditor), so I can certainly see that case where it brings itself to the attention of someone who may not understand the tools.
If we're looking for a scalable solution that'll keep it away from inexperienced users, how about linking its visibility to one of the autoconfirm memberships? — Sasuke Sarutobi (talk) 11:42, 20 May 2017 (UTC)

Setting redirect in options populates after templates when contributed together[edit]

User agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.36

Setting a page as a redirect in the VisualEditor options will populate the redirect line after any content added in the editing pane. This includes redirect templates (such as {{r from plural}}).

URL: https://en.wikipedia.org/w/index.php?title=Service_workers&redirect=no&veaction=edit

Sasuke Sarutobi (talk) 11:36, 20 May 2017 (UTC)

Sorry, to clarify - if the redirect is not the first item on the page, it will not be read as a redirect, so will not work. Please let me know if I need to file this as a bug report. Thank you. — Sasuke Sarutobi (talk) 08:49, 22 May 2017 (UTC)

⟨⟩

Added references[edit]

User agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_12_3) AppleWebKit/602.4.8 (KHTML, like Gecko) Version/10.0.3 Safari/602.4.8

URL: https://en.wikipedia.org/wiki/D,Kr?action=edit

Hello! I added references for this page as it said it could be deleted due to lack of sources and references. I added a few to prove the page, is there anyway to fix this?

Shokrijan (talk) 15:04, 28 May 2017 (UTC)