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

I've recently been using the 'New wikitext mode' so I have access to it's enhanced syntax highlighting.

What would also be appreciated in terms of my "repair" edits would be integration of the search regexps that the tool here Wikipedia cleaner has for identifying CHECKWIKI repairs., There are other semi-automated edit scripts like auto-ed that would also be useful.

I'd also like to see consideration given to integrating something like User:PerfektesChaos/js/lintHint, given that it's currently not compatible with the mode.

Thanks for the suggestions. I think @NicoV is the best person to ask about whether WPCleaner can be made to run in this kind of environment. As for @PerfektesChaos's script, it's possible to install editing gadgets, but I don't know how easy it would be.

Hi. As WPCleaner is developed in Java, I see no wa to integrate it with the new wikitext mode. It would probably require developing a new gadget following the line given by Whatamidoing.

• It is a CodeMirror issue.
• 2017 VisualEditor source mode is involved only by serving a button, but 2006 or 2010 toolbar would have done the same with the similar button.
• On CodeMirror mode the original textarea does not contain the updated wikitext, and it needs to query from the CodeMirror architecture to retrieve the last updated wikitext.
• This weekend I deployed lintHint supporting both wikEd gadget and CodeMirror extension.
• Has been announced at w:de:user talk:PerfektesChaos/js/lintHint #Reporting incompatibility of LintHint.js with 'New wikitext mode' in Beta.
• It does not only evaluate the updated highlighted wikitext but also succeeds in positioning to the source text fragment in doubt.
• VisualEditor itself is not involved in linter business nor lintHint, since there is no wikitext present at client side.

And this update is activated how? I assume the documentation will also be updated?

I do follow a standard procedure:

• If it is a real bug, even more damaging texts, it is remedied and deployed asap.
• If it is a little improvement, it is published in debug state and a small group of test users will deal with that for half a day or a day.
• If there are no complaints a small step will be deployed then for all.
• If the step is very minor and makes no real change for users, deployment to all might be postponed and follows later together with more effective changes.
• If it is a quite big change with some risks (like the issue which is discussed here) the preliminary change will be published for a week before it is deployed to all.
• If that turns out to be stable and it is a major issue worth mentioning in documentation, it will be added one or two weeks later if no problem arrived.

Therefore it might take a month between a suggestion and the documentation of a change.

The update is performed by uploading new JS page contents. If browsers and servers would obey cache intervals it might take further days up to a week.

Running Microsoft Edge, Windows 10 1803 (17134.112), Vector/default wiki skin. Problem also occurs in InPrivate session (signed out, no extensions, etc).

To reproduce, edit a large article so that the scroll bar is showing within the wikitext editor view pane. Scroll down a little. Copy or cut any text within the editor using the keyboard shortcuts.

Only occurs if syntax highlighting is enabled.

This sounds a bit like a bug that @MusikAnimal (WMF) was chasing down a little while ago. Do you have problems only when cutting or copying, or does it scroll inappropriately at other times, too?

I only noticed it jumping when cutting or pasting. However, I have since disabled syntax highlighting in my browser as soon as it became an issue.

This is something that I have been using in the previos wikitext editor. Do we have this available in the 2017 wikitext editor ?

I don't think so. It's been discussed, but I can't find a Phab ticket right now. However, they're all listed on the info page (example).

When I turned on the Beta Wikitext mode, the bold text and the big text from the Wikitext syntax highlighting feature disappears, in both English and Chinese Wikipedia. It doesn't affect the italics though.
Without the new Wikitext mode
With the new Wikitext mode

The syntax highlighting team has made a few improvements. Is this still a problem?

Tracked in Phabricator
Task T184786

Steps to reproduce

1. Try to source edit the template protected page,en:Template:Static_IP, without the "template editors" right. This should display the "This page is currently protected ... message which should also contain the "Submit an edit request" button.
2. Tap on the "Submit an edit request" button.

Expected results

The editor loads for creating a new section with the pre-filled topic "Template-protected edit request on DD MONTH YYYY" and some content in edit box.

Actual results

The editor fails to load showing the "The editor will now load. ... message. The browser's console shows the error "TypeError: Argument 1 of Window.getComputedStyle is not an object." for the mangled code line var l = window.getComputedStyle(t).

Further, if the page is re-loaded using the link found in the message displayed in the page, a different page is loaded which appears to be in an inconsistent state as the UI contains parts of both the 2017 wikitext editor and the OWE.

I believe that the seemingly "inconsistent state" of the icons is the result of https://phabricator.wikimedia.org/T191031, which changed the 2010 WikiEditor's toolbar yesterday.

I'm not pretty sure how this issue is related to the one in task T184786. IIUC, this issue is about editing the talk page corresponding to a template protected page, with pre-loaded content and the issue in task T184786 is about creating a protected page. Regardless, the errors I see in the browsers console for both the issues are the same.

I didn't refer to the icons in the edit toolbar when I said "inconsistent state" (They don't appear to be using OOUI, at least not yet). See this screenshot.

I noted another surprising thing just recently. When I turn off the "Wikitext syntax highlighting" beta feature, a partial inconsistent state is seen. To add to the surprise, the text in the OWE editor window is syntax highlighted despite the fact that I turned off the beta feature.

Note: I corrected the link for "source edit" in the topic description.

(Removed note that belongs in some other thread)

I don't think that's a relevant reply for this discussion. Anyways, the editor seems to behaving gracefully now. It loads completely instead of halting in an inconsistent state. It shows a Javascript error anyhow.

Tracked in Phabricator
Task T197652

Exactly what it says. There can be a serious lag when typing on long pages like w:Wikipedia:Village_pump_(proposals).

yes the problem is there +1

Are you sure that the page has finished loading? Are you trying to edit the whole page or just a section?

@Whatamidoing (WMF) it's loaded, and I was trying to edit the full page. :-)

Hey, I'd appreciate if you followed How_to_report_a_bug. We clearly need more info if we're to report anything (I can't reproduce, so what's different between us?). TYVM!

@The ed17, is this still happening?

@Elitre (WMF) It is. I'm using Windows 10/Chrome with a pretty decent computer. I've just tried to type eight words in quick succession when editing that village pump page, three different times, and it is taking up to ~thirty seconds for all of the words to appear. Shorter pages like w:HMS Dreadnought (1906) also have a delay, but it's more like input lag (not even a second's delay).

(Edit: This happens with and without the wikitext syntax beta feature enabled.)

30 seconds ? that is insane... For me it is near instant. Can you try when starting from this page (disables your gadgets and userscripts) ?

If that isn't any better, can you start up an Incognito/Privacy mode window of Chrome ? That will disable all chrome extensions, when you use Wikipedia, and exclude that it is possibly an issue with a browser addon or something.

I've also experienced a delay in displaying typed characters (delay of about perhaps one second, depending on typing speed), e. g. on the page w:de:Berlin, when editing the whole page (the page was fully loaded before I began typing). If I used the old wikitext editor, the problem did not appear.

Tracked in Phabricator
Task T197487

With the 2017 wikitext editor enabled, I think the preferences in the 'Preview' sub-section of the Editing section don't make much sense.

Something should be done about this. Possibly noting that this only applies to OWE or completely hiding those preferences when 2017 wikitext editor is enabled.

Hi there,

Good point. I've filed this as https://phabricator.wikimedia.org/T197487.

Hi! I've used this new wikitext editor during the last weeks, and most have been pleasant surprises – automatic source templates, ease of editing (all the code visible with no code framing) and speedy moves between VE and this editor (to and from). But I (macOS 10.12.6, Google Chrome 66, Vector skin) cannot seem to get the preview to function when on discussion pages. Often there is a hard freeze, making me have to exit the edit process and start the edit anew. Is this a bug? I'm working on svwp, where Flow hasn't been added to the interface.

I have also faced this problem, so it appears on different computers, operating systems and browsers (the only difference, by the way: I constantly faced slow moves between visual editing and 2017 wikitext editor, especially in the direction from 2017 wikitext editor to visual editing).

OK. My experience of time when changing editor is 2 seconds on small pages (either way to/from) and 5 seconds on large pages (either way). My computer is MacBook Air (8 GB RAM, Intel Core i7 2.2 GHz), delivered last November.

On small pages I experience about the same, but on medium to lage pages, only a change from visual editing to 2017 wikitext editor is performed in about 5 seconds, a change from wikitext editor to visual editing takes about 9 seconds. Under such conditions, I'd stay in wikitext editor mode to complete the edit and neglect visual editing.

I can't reproduce this on Paracel's user talk page at this wiki or at the Swedish Wikipedia. I also tried an article talk page, and I was able to see the preview. I tested in Safari 11.1 on macOS 10.12.6.

Questions:

1. Have you enabled the Visual Diffs beta feature?
2. How are you trying to start the preview (e.g., keyboard shortcut or opening the Publish dialog?)

Hi! I haven't enabled any other beta features (didn't know they were connected). I'm normally hesitant in being a beta tester, but this new wikitext feature is enough bug free to be useful. Two other observations:

1/ When in editing mode, previewing, returning to editing, and then publishing, this last action seem to bypass the Publish dialog altogether, not giving me the possibility to add a publication comment.

2/ When editing a discussion page, the Publish comment field seem to be unreachable.

I most often use the keyboard shortcut to get to the preview, most often using the buttons to navigate from the Publish dialog.

(I'm not an early adopted either. In fact, my team is used to me telling them that Change Is Bad.  :-)

When I enable the 2017 wikitext mode and open https://sv.wikipedia.org/wiki/Användardiskussion:Paracel63?veaction=editsource&section=45 (the last section on your userpage), add some text, and type Control+⌥ Option+p, I get the preview. Preview also works when I click on the blue Publish changes… button, and then on the preview. I've tested this in macOS 10.12.6 in both Safari 11 and Firefox 60. Is that broken for you, on your talk page at the Swedish Wikipedia, in Chrome?

Hi! My bad (memory). No, it works here too. There are other glitches, but they're not serious. Have a nice day.

I've tested showing the preview on talk pages (on non-macOS) again and this time it worked, so this problem seems to be solved.

Bugs that magically disappear make me nervous (because maybe they'll magically come back, too). But I'm going to hope for the best. Do please post again if this bug re-appears in the future. I'd really appreciate it.

I don't have time to thoroughly test all combinations:

*editing article space, discussion, other pages

*starting on VE or Wikitext 2017

*previewing through button or shortcut

*navigating through the four Wt17 preview space buttons: return to edit, review edit, return to publish dialog, publish

*navigation through the above in reverse or alternative order

*other combinations

Things are bound to change depending on situations. In some instances the publish button goes straight to publish, not presenting the publish dialog in between. Some other day I'll return with the exact circumstances, but as of now it seems to be random, or a consequence of some of the 200 possible combinations elaborated above.

The Publish button goes straight to publishing only when you're in a preview or diff screen. (That way, you can type your edit summary, double-check your edit, and not have to go backwards to look at your edit summary again. If you want to go back to the edit summary, then click the "Return to save form" in the lower left.) Advice on improving the design is always welcome.

Thanks. Yes, that seems to be the behaviour I'm trying to get the hang of. It isn't consistent with earlier system behaviour, but maybe it's a better solution (edit summary is not everything).

In the 2017 wikitext editor, the MediaWiki:Edittools aren't available. These Edittools, or their project specific versions like w:de:MediaWiki:Onlyifediting.js (in combination with w:de:MediaWiki:Edittools) or w:en:MediaWiki:Edittools, offer several elements that are not available in the 2017 wikitext editor, like the entity  , the tags <nowiki></nowiki> (also combined to <code><nowiki></nowiki></code>), <includeonly></includeonly>, <noinclude></noinclude>, <onlyinclude></onlyinclude>, or matching character combinations not available in the "often used" section of the character menue (in de-wikipedia e. g. “” and ‘’) and much more. These featueres should be made availabe in the 2017 wikitext editor, either by using Edittools, or on a different way. Beyond that, also elements like <br />, {{}} (for parser function and variables as they can not be added by the Template wizard) and {{{}}} (for parameters) would be helpful.

The "Often used" section of the special character menu is under local control, so the local community can add whatever they want.

Generally speaking, VisualEditor's wikitext mode is "tuned" for article editing, so the team is hesitant to include elements that should not be used in typical Wikipedia articles. If you frequently create templates, then you may be more satisfied with an editing environment that is optimized for that kind of work. (The "old" wikitext editor is still available for one-time edits, even with the beta feature enabled; just change the end of the editing URL to say &action=submit instead of &action=edit).

(I see that you have found T164956 about the line breaks.)

The "Often used" section is the same in the VisualEditor and in the 2017 wikitext editor. To include tags there would probably not be such a good idea, as VisualEditor is intended for WYSIWYG-editing. It would be good, to have a menue especially for the 2017 wikitext editor or a 2017-wikitext-editor-specific extended version of the "Often used" section to place the HTML-entity   or tags like <nowiki></nowiki> or <code><nowiki></nowiki></code> there. Thank you for telling me the possibility to change editor via URL-modification. In the de-wikipedia it only works, when one has disabled the VisualEditor during it's Beta-Phase in ones settings (only then, one get's the old wikitext editor, if one replaces "veaction=editsource" or "veaction=edit" in the URL by "action=edit").

Tracked in Phabricator
Task T192605 Resolved

Generally, it is possible to make a copy of a text passage using drag and drop and pressing the CTRL key while moving the mouse. In this case, a + appears next to the mouse pointer. In the 2017 wikitext editor the + also appears next to the mouse pointer, but the text is moved, not copied (it is deleted from the old position).

Interesting, never knew about that shortcut. I doubt the average user even knows it exists, and even then, Ctrl + C , Ctrl + V is generally way faster than a combo of keyboard and mouse.

Personally, I prefer Linux's approach to copy paste, simply select and middle mouse click to paste. Either way, it seems reasonable to add that functionality, assuming that it isn't complex do to so.

Ctrl + C , Ctrl + V is also a combo of keyboard and mouse, even more keyboard, and mouse to the same extend (i.e. moving from the start position to the target position)

I normally select text with no mouse/pointer at all. At least on my Mac, you hold down the shift key while pressing the arrow keys to select text. I find it to be faster and easier than using a mouse, but other people might prefer other options.

One can actually copy and paste without a mouse since ancient times when Windows / Mac OS and the mouse / trackpad, et al didn't even exist. Heck one can operate any good application or operating system without any mouse at all, in fact, one can even copy and paste without even the mouse or keyboard or similar device.

Anyway, this thread makes the incorrect assumption that this actually works in all operating systems.

It doesn't...

But that is no reason to inhibit it in operating systems in which it actually works and can be used with the old source editor of Wikipedia. By the way, is there any statistics in which operating systems Wikipedia is edited most?

That depends on what you mean by "editing", and where "Wikipedia" is. At the German Wikipedia, I would expect most edits that are not made in a flagged bot account to be done on Windows computers. For some small Wikipedias in developing countries, the most common OS for "fully manual" edits (i.e., not using AWB or similar scripts) might be Android.

And I thought everybody knows this.

What web browser and operating system are you using?

Windows 7 (home) and 8 (office), Mozilla Firefox 59.0.2