2017 wikitext editor/Feedback

Post your feedback about using the first iteration of the 2017 wikitext editor as a Beta Feature. While you can disable it by unchecking the New wikitext mode checkbox in your Preferences (Beta tab), 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. You can learn how to structure well your submission.

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). Also, while editing to reproduce a problem, please try to append &safemode=1 at the end of the URL; if the problem disappears, you are using a gadget or script that interferes with the editor.

We are trying to keep the page tidy by providing links to relevant tasks while closing threads. You can help by adding {{tracked|T######}}. By all means, feel free to re-open a thread if you need to!

See also:

View open developer tasks – Complete workboard – Report a new bug in Phabricator – Join the IRC channel

Tracked in Phabricator
Task T153306

Sure, it's 2019 and we're talking about the 2017 editor, so apologies for being late to the party.

• To preview and return to editing, the process of "Publish changes…" – Preview – back-arrow button – X button is cumbersome and confusing. The number one obvious improvement that could be made to this UI is to add a Preview button to the left of "Publish changes…"
  • Of course, visual mode doesn't need a Preview button, but I don't see a problem in having that be different between the two modes.
  • (I would even argue that publish before preview/test is a generally bad idea for any source-code editing. I'm tempted to advocate to replace Publish with Preview when in wikitext mode, but admit forcing all writers to go through a preview step wouldn't fly.)
  • Flipping between source- and visual-edit mode just to achieve a preview (like with this Flow editor I'm using now) is hard to get used to. Not necessarily bad, but a bit of a shock to the system. If it weren't for the "...and you can preview the result" text, I'd be a bit lost. Ditching the Preview button totally from 2017 Editor and requiring visual-edit-to-preview would be a barrier to adoption.
  • Using the keyboard shortcuts is a great tip for a workaround, but it's still just a workaround. I have to try to remember the modifier keys: was it Alt+Shft, Ctrl+Shft, or Ctrl+Alt? Also, at work I've seen end-users take their hand off their keyboard, grab the mouse, drag the pointer across the screen, home in on the next text field in an application, click it, then return their hand to the keyboard. When they could have just pressed Tab to advance from one field / textbox to the next.
• When in Preview, the "Publish changes" (no "...") button doesn't give me a chance to revisit the edit summary and minor-edit checkbox. The whole thing just goes whoosh.
• Edit-summary overlay is presented like a modal dialog, but from there the Preview button produces a full-page overlay. The animations help this to not feel totally weird, but still
• Combining the points above, what I'd like to see instead is:
  • From Editing screen, two buttons: Preview and Publish... which take you to the preview and edit-summary overlays respectively.
  • From Previewing screen, two buttons: Back which returns you to editing (or to whichever previous screen), and Publish... (with "...") which brings up the edit-summary overlay.
  • From edit-summary box, two main navigation/action buttons: Publish and Cancel/Close/Back. Review Changes to show diff (as in visual mode) would still be good, IIRC the diff isn't full-screen and has a shaded surround?
    • Getting to the preview from here is problematic. Cancel and then preview from the edit screen? Make it a toggled alternate state for the diff-viewer? Both?
• Syntax highlighter has problems with line selection, so I had to turn it back off. This is a pity, since syntax highlighting is a huge benefit when editing or reading code.
• Interaction and animations were responsive on a new, well-specced desktop PC with large monitor. I've yet to try this on a lower-powered, smaller-screened laptop or tablet.
• Cite tool is quite different from the one in the 2010 editor, but it works fine (at least for the simple case that I tried). Didn't notice a preview-before-insert option, le sigh.
• In the "normal" editor, the cycle of alter-preview-alter-preview seems to give some protection against tab reloads, browser crashes, etc. (for browsers that have a reload-last-tab-set feature, which is most of them these days). The visual-based editors don't seem to save any local state against mishaps. To spend a lot of time on a carefully-crafted reply or edit and then lose the lot is extremely discouraging. Do we need to go back to the old practice of intermittently pasting our work into an external text document or notepad?

I do hope that dev time can be devoted to getting this editor out of beta, as it shows promise. A consistent toolbar might be appreciated by some of those who toggle often between visual and source modes(?). Just please please don't make it the only choice nor stop maintaining the old editors.

That's a lot of dot points – as I got carried away by detail – so, to summarise, my Big 3 areas for improvement would be: (1) flow of preview–diff–summarise–publish, (2) syntax highlighting, (3) preserve state against loss.

But I just realised (2) might be for Timeless only? Per Topic:V3ap9inic4lnhfim below.

(2) is probably for Timeless only, and (3) is handled with a (silent) auto-save feature. You might lose a little bit, but you shouldn't normally lose everything.

Oh, which editors are meant to have auto-save? I find it not uncommon to lose content that I've been working on. Could you point me to where the feature is described?

Second impressions

Tried just now with Safari, iOS 9.3.5, Vector skin, "desktop site", 9.x-inch Retina display, iPad 3, touch only (no Bluetooth kbd).

Just a quick test: deleted one word, tapped around the toolbar and publish-changes-related screens.

UI still fairly responsive. Feels just a teeny bit slow, but no worse than many sites on this older device. Only exception is the symbols list (omega button) takes a very long time to show.

I see now that you can already flip between Review your changes and Preview screens (dialogs, modes, views, overlays, whatever is the correct term). The relationship between these two screens and Save your changes makes more sense now.

I can see how people might want to publish directly from the diff or preview screens, but still think there is value in having them return to Save your changes before publishing. At the cost of a single click, it means they get a second chance to see the legal copyright note, and to consider their edit summary.

Perhaps the initial "Publish changes ..." button with ellipses could be renamed to "Review and publish..." to reflect its full function and distinguish it more from the second "Publish changes" button. I do notice on the smaller screen there is less free space on the toolbar to accommodate a second button.

Multi-line selection with syntax highlighting turned on works fine with Vector skin.

Bug? Can't paste into Edit Summary box on this platform.

Did the non-pasting Edit summary contain any sort of formatting (e.g., links or images)? There are some things that it won't let you paste because it can't make sense of them. In that instance, "Paste and match style" (or whatever system the web browser has for pasting unformatted text) usually works.

On further testing, it appears to depend where I copied from. More like a VE copying problem than a pasting problem. Will need to check some more platforms. If this only happens on old iOS versions then there's less reason to fix.

With Safari on iOS, I don't have an option to paste as plain text (I do love Ctrl+Shft+V on desktop Firefox!).

Procedure I'm following is: tap in the text field (edit summary) to activate it; tap at the cursor to activate context menu; observe whether menu says "Select | Select All" or "Select | Select All | Paste".

Desktop view: if I copy some words from 2017 wikitext editing mode or from visual mode, they are not pastable into the edit summary. Text from an external application like Notepad is pastable. For what it's worth, I can't paste the same copied text (from 2017 source mode) into this SD-editing box either. If I try to paste it into Notepad, there is a paste option but no content is inserted.

Mobile view: if I copy text from wikitext editing mode it is pastable, but if I copy the same text from visual editing mode it isn't.

Oh ha ha ha face palm.

On iOS 12 Safari, the VE toolbar gives me a warning alert that I am “using a browser which is not officially supported by this editor”. And yet copying works there.

iOS 9 Safari, no alert but copying doesn't work.

We can probably Let It Go … or maybe Let It Be? The user base of older devices shouldn't be ignored if we want to reach people in rural, impoverished, and international situations (or maybe you have user-agent stats saying it's not that important?). But iOS is served primarily by the mobile view and we don't need every editor to work perfectly on every platform.

@Whatamidoing (WMF): Could somebody list this somewhere for the record as "known issue won't fix", if that's appropriate?

Rural and impoverished situations probably aren't using iOS anything. They're probably using Android.

Does phab:T190291 look like this problem? I'm going to put a link to this discussion there.

Aplikacja klienta: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/76.0.3809.132 Safari/537.36

URL: https://pl.wikipedia.org/w/index.php?title=Puszcza_Bia%C5%82owieska&section=0&veaction=editsource

https://phabricator.wikimedia.org/T212680, workaround is disabling syntax highlighting.

After doing some editing to a page. When you insert a table using Insert > Table, the editor basically becomes unusable. The editor is unusable as in when you try deleting or entering text on one line, the text is deleted or entered on another line. I originally posted this at Wikipedia:VisualEditor/Feedback on the English Wikipedia, but it makes more sense for it to be here. This has been going on for at least a few months now.

See https://phabricator.wikimedia.org/T108447

When using the source editor with syntax highlighter on, when you have links inside a link to a file. The colouring of the square brackets ends at the square brackets for the link and not for the link to the file. If an external link is at the end of a file link (causing ]]]) at the end, the first two square brackets are coloured rather than the last two (]]] instead of ]]]). External links are also not styled when in file links. For example:

[[File:example.png|thumb|This a caption with a [[link]], okay?]] should be...

A) [[File:example.png|thumb|This a caption with a [[link]], okay?]] (link colouring and darker background)

B) [[File:example.png|thumb|This a caption with a [[link]], okay?]] (link colouring)

C) [[File:example.png|thumb|This a caption with a [[link]], okay?]] (no styling / no link colouring)

[[File:example.png|thumb|This a caption with a [[link|display]], okay?]] should be...

A) [[File:example.png|thumb|This a caption with a [[link|display]], okay?]] (link colouring and darker background)

B) [[File:example.png|thumb|This a caption with a [[link|display]], okay?]] (link colouring)

C) [[File:example.png|thumb|This a caption with a [[link|display]], okay?]] (no styling / no link colouring)

[[File:example.png|thumb|This a caption with a [https://en.wikipedia.org external link.]]] should be...

A) [[File:example.png|thumb|This a caption with a [https://en.wikipedia.org external link.]]] (link colouring and darker background)

B) [[File:example.png|thumb|This a caption with a [https://en.wikipedia.org external link.]]] (link colouring)

C) [[File:example.png|thumb|This a caption with a [https://en.wikipedia.org external link.]]] (square bracket colouring fixed)

[[File:example.png|thumb|This a caption with a [https://en.wikipedia.org external link], okay?]] should be...

A) [[File:example.png|thumb|This a caption with a [https://en.wikipedia.org external link], okay?]] (link colouring and darker background)

B) [[File:example.png|thumb|This a caption with a [https://en.wikipedia.org external link], okay?]] (link colouring)

C) Not changed

[[File:example.png|thumb|This a caption with a [https://en.wikipedia.org], okay?]] should be...

A) [[File:example.png|thumb|This a caption with a [https://en.wikipedia.org], okay?]] (link colouring and darker background)

B) [[File:example.png|thumb|This a caption with a [https://en.wikipedia.org], okay?]] (link colouring)

C) Not changed

I prefer option A and I'm fine with either option B or option C. I originally posted this at Wikipedia:VisualEditor/Feedback on the English Wikipedia, but it makes more sense for it to be here.

When I open the "Edit" link for a page in a new tab (in the background), the 2017 wikitext editor doesn't load until I switch to that tab. After switching to the tab, the editor takes another second or two to load, with the progress bar shown. Ideally, the editor should load in the background when it is opened in a new background tab, so users don't have to wait those extra seconds when they switch to the tab.

Sadly this is a decision made by your browser, and we can do nothing about it.

Assuming you are using Chrome, more information can be found here: https://developers.google.com/web/updates/2017/03/background_tabs, including instructions on how to disable this for yourself with a flag.

Thank you for the explanation!

Tracked in Phabricator
Task T231988

When I press PgUp, it scrolls to the beginning of text; similarly, pressing PgDn scrolls to the end of text. Firefox 68, Windows. Also, tool buttons are way too big (about 3 times larger than font size). And, of course, no preview button is a deal breaker.

1. What do you expect the PgUp/PgDn buttons to do?
2. The buttons are big for accessibility reasons.
3. The Preview button is inside the Save/Publish dialog. You can also use the same keyboard shortcuts that work in the older wikitext editors, e.g., alt+⇧ Shift+p.

1. Move cursor one page up/down, not scroll entire screen. Right now it scrolls one page (as it should), pauses for half a second, and then scrolls entire screen to the top/bottom.
2. Ok. Though I'd like an option to make them smaller (on 27 4k monitor with 200% scaling they look huge)
3. Still don't see it. I have Save and View changes (diff) buttons, no preview. Alt+Shift+P does nothing.

1. I can reproduce this in FF, so have filed as T231988. (This appears to be a bug in Firefox)
2. You could write some custom CSS to make them smaller for yourself, but I don't think it's worthwhile us making this an option in the software.
3. I can see the show preview in all browsers, are you sure you are in wikitext mode, and not visual mode?

I am a heavy user of de:User:TMg/weblinkChecker (my own fork de:User:Boshomi/externalURLform.js) for external link maintenance (i.e InternetArchiveBot cleanup) or scripts like Autoformater, or text replacement Tools like de:User:Boshomi/ARreplace

I is possible to integrate edit helping tools to this new wikitext editor? or is there some help for adapting existing tools? Boshomi (talk) 22:04, 29 August 2019 (UTC)

See VisualEditor/Gadgets for a guide on how to write gadgets for VE or the 2017 wikitext editor. You can also use the text selection API but this will create a transaction to replace the whole document.

Hello, I would appreciate the option to turn off animations (for dialog boxes, etc.) in the 2017 wikitext editor. The animations slow down editing slightly, and more importantly, they make the editor feel less responsive.

Can you tell me what kind of computer you're using?

I've tried the 2017 wikitext editor in desktop browsers on different desktop and laptop computers across Windows, macOS, and Linux. The behavior is the same on every platform. The animations aren't a major performance issue, since they take less than a second. However, the 2017 wikitext editor is already slower than the existing wikitext editor, and these animations make the interface feel even slower (especially for editors who are used to the existing wikitext editor). It's a perception issue, and I think it might discourage editors from adopting the 2017 wikitext editor.

To clarify, I'm referring to the animation of the display of the "Find and replace" panel, the "Special character" panel, and the "Options" dialog box. In contrast, the display of the "Link", "Cite", and "Help" tooltips feel more responsive because they are not animated.

@JKlein (WMF): I think this discussion might interest you.

Our animations take 250ms, and help users keep oriented when the interface changes dramatically. Almost all of our transitions are implemented in CSS, which means the browser only updates during spare CPU cycles, so it shouldn't negatively affect actual performance.

Animations are built into our user interface library OOUI in many places in the JavaScript and CSS, so turning making them optional would unfortunately be an extremely complex undertaking.

Okay, I understand. Thanks for your consideration.

I also prefer not to have animations. My complaint is a bit more general - apologies if I am hijacking this thread.

When editing, I don't want to see the little keyboard icon appear in the lower-right corner, and then exactly two seconds later vanish by moving upwards. That happens every time I switch to the browser window in I3, and it's annoying.

Also, I found out how to keep the action tabs ("Edit", "View History") from "animating away": switch back to Monobook in Preferences. This animation occurs when I make the text large or the window small; the page tabs to "Edit" or "View History" or "Watch" animate their disappearance into the "More" menu, which is annoying since it slows the page loading and distracts me visually. I don't need a constant reminder that the "More" menu contains stuff.

I'm also annoyed by the fact that even when I enable "source editing" on this website, the result is apparently not a normal HTML text area, and so I can't use Itsalltext in Firefox to edit it with my preferred text editor (Emacs). I hope that this doesn't happen when Wikipedia and Wiktionary upgrade to the latest Mediawiki. I haven't tested it with Textern which is the modern replacement to Itsalltext. It would be annoying to have to copy and paste every edit I make, like I'm having to do now. I would basically stop contributing to those projects until I found a fix.

I got here by Googling "how to turn off mediawiki animations", please let me know if there are other places I should put this comment. Thank you.

I might be interested to know if there is a simple CSS hack which can turn off animations; although I would prefer something more accessible to users.

Which of the many editors are you using?

That's a useful list, thanks Whatamidoing!

I think the animations should simply go away. The submit popup, preview popup animates and this is annoying. I don't think that my browser is slow, the animation interrupts the work flow.

Tracked in Phabricator
Task T230756 Resolved

When I turn on syntax highlighting, the text becomes displaced, appearing one line below where is actually is.

• 
  Ctrl+A displaying where text actually is (using DE screenshot tool)
• 
  Ctrl+A displaying where text actually is (using Firefox screenshot tool)

I was able to produce this bug on FreeBSD using Firefox 67 and on Android 8.1 using Brave 1.0.99.

Addendum: This only appears to affect users using the Timeless skin.

Thus, to reproduce the bug,

1. Switch to the "Timeless" skin in Special:Preferences.
2. Enable "New wikitext mode" in Special:Preferences.
3. Enable "Syntax highlighting" in the New WikiText Editor.

Timeless is a volunteer-supported skin. @Isarra, are these problems between Timeless and CodeMirror already in documented in Phab:?

Okay, the issue has been solved.

When I paste some text in Firefox into editor, it is white and is background. Some text can be above the pasted text, but Firefox allow pick out bugged text. Please, see the screenshot: File:New Visual Editor bug in Firefox.png.

Does this happen if you "Paste and Match Style"?

I don't know. Just see my step-by-step reproduction: File:New Visual Editor bug in Firefox (step 1).png → File:New Visual Editor bug in Firefox (step 2).png → File:New Visual Editor bug in Firefox (step 3).png. If you talking about Ctrl+Shift+V: alt step.

I'm so sorry. This bug is only on my profile. I guess, I have some breaking extensions.