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

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.

I tried it quickly in Chrome, but if fails for me. Possibly it clashes with some other gadgets or such I have, but what happened is that on talk pages I couldn't find the signature button (I don't know where it is hidden in the Visual Editor menu). Also, it disabled the synatax highleter I find very helpful for code editing. So I am not sure what this is supposed to do better - I use visual editor sometimes, but at the very least this shouldn't cripple code editing and hide signature buttons.

The "Your signature" button appears under the "Insert" drop-down menu, and the "Syntax highlighting" button appears under the Menu icon (three horizontal lines) drop-down menu.

The Visual Editor suffers from the same drop-down menu scavenger hunt issue found in other WYSIWYG editors. The developers might want to rearrange things more intuitively and give greater prominence to the signature button on talk pages.

I'm used to edit in a second and this editor is slower and adds summary screen to the flow. Over 7 seconds for a simple edit.

I also feel this problem. This problem occurs due to load of traffic while editing.

Tracked in Phabricator
Task T153367

Aplikacja klienta: Mozilla/5.0 (Windows NT 6.1; rv:52.0) Gecko/20100101 Firefox/52.0 SeaMonkey/2.49.4

1. Preview with ability to display Lua log messages from mw.log()

2. Preview with possibility to specify another page as base (preview template on another page)

3. Preview shouldn't cache docs pages - changes in template doesn't reflect in template docs in preview.

(Workaround: action=submit - but beware that it doesn't preserve the changes you made before switching!)

And as a bonus: possibility to insert nowiki tags.

Why would you want to use this editor, instead of the Extension:CodeEditor, in the Module: namespace?

I was talking about the preview screen (in Article/Template Namespace), not about making this editor available for Module namespace. I may be wrong, but there's no possibility to display Lua log messages on preview screen (or that option is not very visible).

In "New wikitext mode", if the cursor is on the last line of a paragraph, and there is a blank line below and then another paragraph: if I press the down key, instead of moving the cursor to the blank line, it moves to first line of the next paragraph. That is, it skips the blank line.

This is so annoying I've disabled New wikitext mode. There should be an option to disable this "feature".

Tested in Chrome version 74.0.3729.169 (Official Build) (64-bit) at the English Wikipedia.

Thanks for the bug report; I noticed it last week too, and filed as T225546. The task has been accepted by the team into their "current work" board, and hopefully it will be fixed soon.

Tracked in Phabricator
Task T153306

From [en:WP:KB]: on Windows, Chrome hold Alt+⇧ Shift or Alt+Control+⇧ Shift or Alt, then press p for preview, or v for changes (diff). The modifier key can be different per browser. Note: neither of these works for me in Visual Editor on Chrome, but it's worth a try. - Aron

From the Phab [Task T153306]: Alt+⇧ Shift + p or + v will take you to preview/diff. - Aron

On Mac, it's Control+⌥ Option+p and Ctrl+⌥ Option+v for preview and diff. - Whatamidoing

Please include a "preview" button next to the "save changes" ("Änderungen veröffentlichen")-button! It's nice that the program kindly reminds me to do so after I hit the save-button and for newbies, which would probably not use the preview-button at all it is fine, but as a user who is used to the old editor I got panic as it looked like I had only the option to save the changes without a previev :) --~~~~

Yeah, a preview button before the "save changes" button would be nice. I would really like not to have to click save changes to preview my changes

I agree.

I have found it worthwhile to learn the Keyboard shortcuts for this command. They are the same ones that you use in the older wikitext editors.

Maybe I am blind but I can't find a shortcut for preview in the overview you linked above :(

Can you write it here?

Oh, my fault! You need the main list at m:Help:Keyboard shortcuts, not the extra handful added to VisualEditor.

On my Mac, it's Control+⌥ Option+p and Ctrl+⌥ Option+v for preview and diff. The meta keys are different in Windows (and sometimes by web browser).

@Aron Manning, you should feel free to post your own content in your own message.  :-)

For everyone else, Aron has added the Windows keyboard shortcuts:

From the Phab Task T153306: Alt+⇧ Shift+ p or + v will take you to preview/diff.

From WP:KB: on Win, Chrome hold Altor Alt+⇧ Shiftor Alt+Control+⇧ Shift, then press pfor preview, or vfor changes (diff). Note: neither of these works for me in Visual Editor. - Aron

@Whatamidoing (WMF)

 :-) Did not intend to ruin your comment. I hardly noticed your updated link down here... Can I suggest you to update the link in your first comment, and copy the shortcuts there? Feel free to copy the chrome shortcuts too. It would have been helpful to me, thus I believe it will be helpful to others. Thanks.

Ping to move discussion to top. More important than testing copy-paste.

^{This might be off-topic here.}

It quickly spams the page history though. Tips for that:

• Consecutive edits of the same message (by the same user) should be merged into one edit/diff/commit, similar to the "Amend last commit" feature of git.
• Consecutive edits of different messages by the same user should be grouped in the history view. Motivating example: just look at this mess I made.

Another usability observation: The .flow-menu ellipsis could be easier to pair with the message it belongs to. As there is no visual separation between messages – the user name on the left side is the only boundary, but the ellipsis is on the far right –, every time I accidentally open the flow menu of the next message...

Imo the flow-menu ellipsis just right from the user name would be more obvious, and closer to where the mouse usually is. The (talk | contribs) links also show up there, when the mouse hovers over the user name. The links could show up right of the ellipsis, or the ellipsis could hide when the links show.

The "Edited an hour ago" (.flow-post-timestamp) is also on the far end (actually the ellipsis menu of the next message is easily associated with it, causing the above issue). Imo this would be better placed where the "(talk | contribs)" links (.mw-usertoollinks) are, and hidden when the user links become visible.

@Jorm I know there's no plan to re-design Flow any time soon, but I thought you'd like to see Aron's feedback on the … menu. I've also encountered the problem of timestamp #1 looking like it's supposed to be related to ellipsis #2 occasionally before.

I had nothing to do with this design. I don't think it's optimal. I was removed from the project before it got to this. This is not what I would have built.

After reading some of the current talk page discussion, I see now the issue with history was a major reason for the refusal of Flow. That discussion might propose a better design.

The ellipse menu UX would be a simple improvement though (some CSS and an element relocation). I wonder where is the forum for such feedback/suggestions?

Fixing the copy-paste issue would be beneficial as well.

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.

Tracked in Phabricator
Task T223191

The edit summary preview doesn't work. It just shows the placeholder $1.

It is very hard to rewrite text, and it loads slow like Visual Editor.

I'm sorry that it's slow to load.

Can you tell me more about problems with re-writing text?