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

It seems that the beta function omits the signature button on article and user talk pages on de:wp. I would like to see it back ;-)

The signature is in the "Insert" menu, about four items from the end.

What benefit does that have? Instead of just klicking the signature-button, I have to klick "Insert", then "more", and then the signature button. I don't understand the reason, it is less usable like that.

The theory seems to be that all the buttons will always be in the same place. Wikipedians probably don't want a signature button prominently displayed to people who are writing articles.

You might also be interested in the Talk pages project/replying tool, which automatically adds the signature for you.

Huh, I'm an active Wikipedian since 2006 and I have always found the advantages of a prominently placed signature button greatly outweigh its disadvantages. Just my two cents.

Sure, but even if we did so, the toolbar is full (in fact, already has if anything too many buttons, per testing). So, which button do you propose removing so that we could add signature to the primary toolbar?

• Undo
• Format (headings)
• Style
• Link
• Cite
• Structured (lists)
• Insert (everything)
• Special character

When I used this editor to preview a table with nested userboxes in cells, it was all fine. However after I submitted, I was surprised to see the table was a mess. I know that userboxes may conflict to table because they also can be seen kind of tables, and I fixed the mess successfully by solving the conflict. But it is still weird that this editor cannot display this conflict. My browser is FF 71 on windows 10, and my skin is Vector.

Previews are a known issue. The preview was deliberately designed to work differently than previews in the normal editor. Almost three years ago there was an overwhelming consensus at English Wikipedia to block deployment of the 2017editor, for design flaws including-but-not-limited-to previews and performance.

It's long overdue to remove the 2017editor from the betatest feature list.

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?

It started to annoy me (PgUp/PgDn), so I ended up here.

Status update: it will be fixed (we'll see about that) in Firefox version 72 (not released yet).

Hi! I've been using the editor for some time after it first came out, but I abandoned it. Now I decided to give it another try, but found, that its major issues (which are quite crucial for me) haven't been resolved. They are:

• Having to click twice (instead of one click) to publish the changes. There's plenty of space below the edit field, so why don't you make the "publish changes" and edit summary window static instead of an annoying pop-up?
• A signature button that is difficult to reach. Again, 3 clicks instead of one, just to insert my signature. It should be more prominent, at least on talk pages.

The above adds up to 5 clicks in total. I'm a sysop on my home project, and sometimes I summarize tens of discussions in a single day. Having to make 3 extra clicks every time I close a discussion, is really, really annoying (at least for a person accustomed to a regular wikitext editor). I, personally, would like the 2017 wikitext editor to be either adjusted, or made adjustable (user-side), so that I could actually use it

I have the same problem with the signature button. It is pretty obvious that "signature" is one of the most frequently used buttons when editing talk pages, so why is it hidden in a menu?

Is the tilde (~) button not on your keyboard? Most people with English keyboards just type the wikitext code for signatures (~~~~) by hand, rather than clicking a button. (This sometimes leads to us trying to sign our e-mail messages in wikitext, too. ;-) ) But that doesn't work if the tilde button is hard to reach on your keyboard.

I'd be interested in your thoughts on the Talk pages project/replying project, which will auto-sign your comments.

My home project is ukwiki, and on Ukrainian language keyboard you have to switch to English to type your signature. Besides, we prefer the --~~~~ signature, so it ends up in having to type 6 symbols instead of clicking only one button on the standard toolbar (you can change the signature itself in the preferences, but the newbies often don't even know how to sign their messages, not to mention changing their preferences). Anyway, saying that "most people type..." doesn't really count, otherwise you could use that same argument to remove the button for good.

As for the project - that's a quite interesting approach, I like it. Though reply buttons become greyed out after you click one of them, so if you missclick a "reply" button, then go elsewhere on some huge talk page, you'll have to find the missclicked button to "cancel" the dialog just to be able to reply to someone else's comment. I think that this potential issue should be taken into account.

Oh, yes, we do have the tilde on german keyboards. That's how I used to sign when I didn't know where the signature button was hiding. It's just not convenient when you are used to click a button that inserts four tildes for you ;-)

I found out by the exception method that this beta function is a weak fragment. When I try to edit text in wikitext editor full-screen mode, the following bug occurs.

The text pointer moves to the right relative to the true position of the mouse. And this is getting harder and harder when you scroll down the text.

12 34 56 78^

For example, I put the cursor on the checkmark "^", the pointer falls to "2" within the text.

Ailbeve, is this still a problem? Does it happen at all wikis, or only at the Russian Wikipedia? Do you have the colorful Syntaxhighlight turned on?

If it is still broken, what is your computer operating system and web browser? For example, I'm posting on macOS Mojave 10.14 in Safari version 13.0.0.

Not. I can’t reproduce such a problem at present.

But. There is a related problem: when inserting a table using tools, a VERTICAL shift of the row representation occurs.

Screen: https://drive.google.com/file/d/1MjI_phElU8Spf4ReofyZ5T77Mrec7evd/view?usp=sharing

Win10 (1909), Chrome 64 (79.0.3945.88)

Does this happen if you turn the syntax highlighting off?

As can be seen in [https://de.wikipedia.org/w/index.php?title=EULAR&diff=cur&oldid=194336791&diffmode=source this] edit on de:wp, when trying to create a redirect, the beta function added nowiki-tags to the hash, as a result the Redirect of course did not work. The tags were not shown in the edit-window before publishing the edit.

It looks like you made that edit in visual mode instead of wikitext mode (indeed the edit tags confirm that). Typing a # in visual mode will wrap it in <nowiki> to prevent it being converted to a list. I can't reproduce this in wiktiext mode.

Not really. At the time I used the beta function "new wikitext", which is wikitext but creates nowiki-tags like the visual editor does, but does not show them. That's the reason I stopped using the beta-function.

Okay, I see what happend. The "create page"-link opens the visual editor. Geez, Wikipedia never stops surprising me.

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.

Yes, that's exactly it, Whatamidoing. And Belezzasolo described it more succinctly than I could. Thanks for adding the comment to that task.

Good point about Android.

I just want to echo Pelagic's comment about the very confusing Preview flow. I tried as hard as I could to predict what would happen when I pressed "Publish" again while in Preview mode, but it still didn't do what I expected (i.e., it didn't do what had happened when I'd pressed an identical-looking "Publish" button just moments before to get into Preview mode in the first place). As a result, I ended up accidentally publishing this change without the edit summary that I had intended to give it.

رابط کاربر: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.120 Safari/537.36

URL: https://fa.wikipedia.org/wiki/%D8%AB%D9%85%DB%8C%D9%86_%D8%B3%D8%A7%D9%84%DA%A9?action=edit

در هنگام ویرایش متنی جعبه ابزار نمایش داده نمی شود. نمیتوانم عکس را بارگذاری کنم

رابط کاربر: Mozilla/5.0 (Linux; Android 9; MHA-L29) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/77.0.3865.92 Mobile Safari/537.36

URL: https://fa.wikipedia.org/w/index.php?title=%D8%A8%D8%AD%D8%AB_%DA%A9%D8%A7%D8%B1%D8%A8%D8%B1:Hassan_Agha_Seyed_Abolghasem&section=new&veaction=editsource

I've been trying to copy two lines from one message to the other for 10 minutes and failed with both visual and source editor. The textbox content gets messed up as soon as I start editing the copied content. If I don't edit, just Save the message, it does not change at all.

On Wikipedia, or in this message system?

^{In the Flow "structured discussion" editor, which I did not distinguish from the Visual Editor, as they are quite similar.}

Right here. I guess there's an internal state for the editor that is not updated with the pasted content, as it is visible, but not saved. Chrome on Win

This seems to have improved from last time, pasting from source editor to source editor now works, with markup, formatting, links all preserved.

Pasting formatted text, links, html content will show up with the formatting in ***both*** source and visual editor, but changing to and back between editors reveals that only the text remains, all markup is stripped.

I believe the expected behaviour is: pasting to source editor shows the markup (source) of the pasted content, and pasting to visual editor retains the markup, while showing the formatted (visual) result. Will do some more tests.

Test paste link to visual: From WP:KB: on Windows, Chrome hold Alt+⇧ Shift or Alt+Control+⇧ Shift or Alt

Test paste link to source: From WP:KB: on Windows, Chrome hold Alt+⇧ Shift or Alt+Control+⇧ Shift or Alt

Test paste source markup to source: From WP:KB: on Windows, Chrome hold Alt+⇧ Shift or Alt+Control+⇧ Shift or Alt

Test paste source markup to visual: From [https://en.wikipedia.org/wiki/Wikipedia:Keyboard_shortcuts WP:KB]: on Windows, Chrome hold {{Key press|Alt|Shift}} or {{Key press|Alt|Control|Shift}} or {{Key press|Alt}}

Test paste link from visual editor to visual editor:

Paste from visual editor to visual editor: From WP:KB: on Windows

Paste from rendered html to visual editor: From WP:KB: on Win, Chrome hold Altor Alt+⇧ Shiftor Alt+Control+⇧ Shift,

Copy-Paste simple text from this visual editor to itself: from rendered html to visual editor

Copy-Paste link from this vis editor to itself:

Note: At this point - after deselecting the link - the visible html widget was updated with the plain - no link - text.

Note 2: Pasting a link will add style="background-repeat: no-repeat, repeat; [... many background styles]" to the <A> element, repeating the tiny arrow behind the link text, making it unreadable. This is unnecessary, the .external style takes care of it. Just editing a previous message won't add inline style to the links.

This confirms: markup is stripped in both source and visual editor, but the proper, formatted html is show (in both), until the text is selected and deselected, when it is replaced with the plain stripped text.

Copying from source to source editor works properly.

Pasting from notepad is lost, see below.

Pasting from notepad:

Try again:

From notepad to source editor:

Paste from rendered html From notepad:

It seems its pasted in the wrong element: Yes, it's not wrapped in a <span class="ve-ce-branchNode ve-ce-contentBranchNode ve-ce-paragraphNode">

Note: this thread wastes a lot of space, and should be removed or archived once this is fixed.

Fixing the wikitext-to-wikitext-mode pasting problem requires dev time, and this tool isn't getting much attention right now. Certain kinds of wikitext get "sanitized" in this editing system before being saved.

These tests show the problem with sanitization is upon pasting the text. My first observations mentioned saving, but it happens earlier.

2. It's still not clear to me, how this flow-editor (both source and visual) are related to the standard wikitext editor (both source and visual). Is it the same software in some parts, or completely different? The design (toolbar icons) are the same, the only difference I see is a more extensive toolbar in wikitext editor.

The point of me asking this is: should I move this thread (the above Flow editor tests) to an appropriate Flow feedback talk page (which I did not find...)?

3. I saw the Flow was tested and rejected an enwiki. While I sense the community's unwillingness to change, the inability to copy-paste into chat would be a deal-breaker for me too. I'm interested how this and the ellipsis menu UX can be fixed.

The Flow (aka Structured Discussions) editor is sort of the visual editor, with a smaller toolbar. But it doesn't (currently) store the contents in wikitext, so if you give it wikitext or want to extract wikitext, then it runs the relevant parts of the database record through Parsoid to get wikitext. The differences between the two parsers is small and diminishing (eventually, the "two parser" problem will be solved by removing the old one and doing everything in wikitext), but there are a few quirks at the moment, including the fact that it "sanitizes" unbalanced HTML. So if, for example, you were to paste in part of a wikitext structure – maybe [[link or {{template – it may behave unexpectedly.

You can type <pre> tags (the wikitext and HTML code) to trigger a window that will let you paste in whatever fragments of code you want to discuss.

My test was to copy a link from the flow discussion in the web browser (thus html) to the editor. The resulting problem (the pasted content not wrapped in a span) could be observed without saving the message. That unwrapped content was ignored/trimmed by the conversion. I would assume the database was not involved in this process, otherwise editing would be very slow with a web request on each edit. I think this was a bug in the javascript implementation of the editor. Once I'll take the time and find the bug in the code, but now I only have the observation. Furthermore, I can't reproduce it atm. Maybe it has been fixed?

Thanks for introducing me to Parsoid, btw.

Seems to be fixed. Text is not wrapped in a <span> inside the <p> elements now. Text I paste into either VE or SE is kept and converted, when I switch to the other editor (both ways).

Test: Aron Manning (talkcontribs)

Works well.