2017 wikitext editor/Feedback/2019

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

Lack of Preview option on main editing page

Tracked in Phabricator
Task T153306

On the initial, main editing page of this editor, there is no option to preview one's work. There is only a big button which says ''Publish''.

This leads one to think that one's only option, after having composed one's edit, is to publish it directly, without having an opportunity to first preview one's proposed changes. This is confusing, disorienting, and in every way bad and undesirable.

I've been editing since 2006, and it threw me off severely. I can only imagine how new and novice editors must feel.

Please add my voice to the many who have already pointed out this terrible flaw in the interface of the editor, and who request an immediate change. ~ Catsmoke (talk) 11:50, 4 January 2019 (UTC)

Disadvantages of this editor compared to text editor

Disadvantages of this editor compared to text editor:

*(in preview) citations preview (by hovering mouse pointer on citation number [1]) doesn't work,

*needs one click extra to see a preview,

*no simultaneous preview and edit (maybe option to open preview in new tab/window?),

*no preview with another page (useful for template editing or doc pages for templates using PAGENAME),

*when progress of loading visual editor stucks, this editor doesn't load either. MarMi wiki (talk) 18:07, 16 January 2019 (UTC)

Comment ajouter une étoile ?

Agent utilisateur : Mozilla/5.0 (X11; Linux i686) AppleWebKit/537.36 (KHTML, like Gecko) Ubuntu Chromium/71.0.3578.98 Chrome/71.0.3578.98 Safari/537.36

URL : https://fr.wikipedia.org/wiki/Hippolyte-Jules_Pilet_de_La_Mesnardi%C3%A8re

Dans la section "Jugements", il y a un cas "̇Jean Chapelain", je veux ajouter un autre cas. Impossible d'ajouter une étoile. Si j'appuie sur le caractère "étoile", ça m'affiche un truc bizarre. Moi qui suis habitué à l'éditeur emacs, je ne comprends pas pourquoi on ne peut pas ajouter du texte "tel quel". Wku2m5rr (talk) 02:36, 18 January 2019 (UTC)

When you type an * at the beginning of a line, in the visual editor, it converts it into list formatting. If you don't want that, then press the Escape key to get a plain asterisk ("star"). Whatamidoing (WMF) (talk) 19:21, 15 April 2019 (UTC)

How can I use the traditional wikitext editor while the beta version is turned on?+ More things

Tracked in Phabricator
Task T217084

It seems like I CAN NOT choose my editor version by simply changing my URL links.

For example, when I request ...?action=edit with "New wikitext mode" checked, I go to the new version....?veaction=editsource...?veaction=editsource&venoscript=1 also go to new version.

But when "New mode" unchecked, links over lead to traditional/view_page/view_page. But ...?veaction=edit with "Visual Editor" unchecked can lead to the visual editor.

And something additional:

(Bug) Non-latin characters in the editor can cause many problems, just like unproper wrap in visual (In a word, when I selected some characters in line X, and 'Delete'. Words in line X+1/X-1 has been deleted.) and failure to insert characters at the head of the line.

(Feature) When I use proxy to edit and view some wikimedia project (Banned by goverment), it has a slow connection speed and low-raliablity transfers. Yes... You can guess what I wanna to know is the cache of the wikitext editor data/js/css file. Can these files are preloaded with other JS file or can be cached for freqently use.

Sorry for poor English, Thanks :D 小老虎3018 (talk) 17:11, 26 January 2019 (UTC)

Use ...?action=submit to get an older wikitext editor.

Whatamidoing (WMF) (talk) 18:11, 22 February 2019 (UTC)

Can you tell me which web browser and what kind of computer you're using? For example, many editors use Chrome on Windows 10, and I'm currently using Safari Version 12.0.3 (13606.4.5.3.1) on macOS High Sierra 10.13.6 (17G5019).

Also, if you know what "IME" or keyboard systems you're using, that might be helpful, too. Whatamidoing (WMF) (talk) 18:15, 22 February 2019 (UTC)

Thanks for reply.

When I got into the bug I'm using Chrome 71+, Windows 10 (1809) and MS Pinyin IME (Windows original). But recurring this issue again is hard for me now because I am using Linux... With Linux + Chrome/Firefox, it's fine. 小老虎3018 (talk) 16:02, 24 February 2019 (UTC)

Option to turn off animations

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. Newslinger (talk) 23:38, 26 January 2019 (UTC)

Can you tell me what kind of computer you're using? Whatamidoing (WMF) (talk) 18:16, 22 February 2019 (UTC)

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. Newslinger (talk) 11:11, 23 February 2019 (UTC)

@JKlein (WMF): I think this discussion might interest you. Whatamidoing (WMF) (talk) 05:39, 26 February 2019 (UTC)

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. ESanders (WMF) (talk) 19:54, 11 March 2019 (UTC)

Okay, I understand. Thanks for your consideration. Newslinger (talk) 22:59, 19 March 2019 (UTC)

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. Initiations (talk) 17:30, 30 July 2019 (UTC)

Which of the many editors are you using? Whatamidoing (WMF) (talk) 18:07, 2 August 2019 (UTC)

That's a useful list, thanks Whatamidoing! Pelagic (talk) 04:16, 29 August 2019 (UTC)

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.  « Saper // talk »  13:25, 6 August 2019 (UTC)

Couleurs

Tracked in Phabricator
Task T216458

Agent utilisateur : Mozilla/5.0 (X11; Linux x86_64; rv:63.0) Gecko/20100101 Firefox/63.0

URL : https://fr.wikipedia.org/wiki/Wikip%C3%A9dia:Wikimag/2019/7/Entretien?veaction=editsource

Il faudrait peut-être changer certaines couleurs, qui sont les mêmes pour des choses assez différents (gras/italique doit être de la même couleur). AirSThib ^{🌌 Cyclist stars cafeteria 🚴} 13:35, 16 February 2019 (UTC)

You can change the colors for your own account by following the directions here: m:Community Tech/Wikitext editor syntax highlighting#Color and style customization Whatamidoing (WMF) (talk) 20:06, 19 February 2019 (UTC)

Friction surrounding previews

Tracked in Phabricator
Task T155732

I think there's a lot to like about the new wikitext editor, but I am reluctantly disabling it because of the awkwardness of the preview functionality. I use previews a lot when editing. With the old wikitext editor my flow would look like... edit, click Show preview, edit, click Show preview, etc.

With the new editor, that flow has become... edit, click Publish changes, click Show preview, click Resume editing, edit, click Publish changes, click Show preview, click Resume editing, etc. It feels like a real drag. Just having a "Preview" button available from the editor (without having to go through Publish changes) would be a big improvement. Extra points if an option is given to show the preview on the same page as the source editor (above/below the text area, as in the old wikitext editor, or side-by-side). Colin M (talk) 17:33, 20 February 2019 (UTC)

This is a relatively common request from people who are used to the older wikitext editors. I don't know when it will be improved, but I know that the team is aware of this request.

In the meantime, I have found it worthwhile to memorize the m:Help:Keyboard shortcuts for preview and show changes. On a Mac, that's Ctrl+⌥ Option+p for preview and Ctrl+⌥ Option+v for show changes. Remember that Esc will get you out of that overlay screen. Whatamidoing (WMF) (talk) 23:16, 21 February 2019 (UTC)

is there a syntax hilighting ?

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

default wikitext editor has syntax hilighting optionnaly enabled, it is possible to do with new wikitext editor ? Xavier Combelle (talk) 17:57, 20 February 2019 (UTC)

Yes. Look in the "hamburger" (☰) menu, towards the end of the list. Whatamidoing (WMF) (talk) 23:08, 21 February 2019 (UTC)

thanks Xavier Combelle (talk) 17:41, 22 February 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Text editing issue

Tracked in Phabricator
Task T221039

I'm on mobile if that helps. Ok so on https://en.m.wikipedia.org/wiki/Draft:RPG_Limit_Break I accidentally paragraphed a T by itself and when I go to fix it, it moves my line where the text goes before the T without me doing anything but hitting the back button. And when I hit publish only the T is there. Not sure if that's because of you guys or not, but when I uncheck the box in beta features and click save, doesn't actually save it and I tried changing it a couple of times. Sorry if this doesn't affect you at all HaiZebrazach20062 (talk) 21:52, 24 February 2019 (UTC)

I helped clean up the specific edit. It looks like this was a mobile VisualEdit rather than a 2017Wikitext edit, so I'm not sure it's relevant on the 2017 feedback board. I'm not sure, but VisualEditor might have misbehaved because the infobox somehow got embedded in the middle of the lead paragraph. I don't think VisualEditor likes it when infoboxes get concatenated with surrounding plaintext. Alsee (talk) 23:58, 24 February 2019 (UTC)

Preview button

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 :) --~ Lesendes Okapi (talk) 10:53, 27 February 2019 (UTC)

I agree too. Ivanics (talk) 16:28, 23 July 2022 (UTC)

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 Erentar2002 (talk) 16:38, 7 March 2019 (UTC)

I agree. Paucabot (talk) 08:53, 8 March 2019 (UTC)

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.

Whatamidoing (WMF) (talk) 20:14, 15 April 2019 (UTC)

I agree. Ivanics (talk) 16:29, 23 July 2022 (UTC)

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

Can you write it here? Lesendes Okapi (talk) 11:00, 1 May 2019 (UTC)

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). Whatamidoing (WMF) (talk) 15:05, 3 May 2019 (UTC)

@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) (talk) 21:55, 31 May 2019 (UTC)

@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. —Aron Man.🍂 edits🌾 22:39, 31 May 2019 (UTC)

Ping to move discussion to top. More important than testing copy-paste. —Aron Man.🍂 edits🌾 17:46, 4 June 2019 (UTC)

This was reported on plwiki technical noticeboard, too: https://pl.wikipedia.org/w/index.php?title=Wikipedia:Kawiarenka/Kwestie_techniczne&oldid=57207917#Powr%C3%B3t_do_edytowania_(Priority_low)

The editing flow is very confusing to me, and shortcuts are not a solution to the problem.

I personally prefer edit -> preview -> edit -> preview -> edit -> preview -> submit flow, and the submit button should be not the first one to reach. Also the preview should be smoothly integrated in the editing flow and not be an extra thing that pops up with an animation. This way no user will feel like using it.

For normal editing I am pretty happy with old wiki editor and the live preview feature (it has its issues but it works very snappy).

This feature forces me to do an "edit -> submit -> maybe preview -> have a look -> go back -> edit

flow" which is cumbersome and unnatural.  « Saper // talk »  13:22, 6 August 2019 (UTC)

Yes, the best flow would be: edit -> preview -> submit (or preview again) Ivanics (talk) 16:36, 23 July 2022 (UTC)

I also prefer edit -> preview -> edit -> preview -> edit -> preview -> submit, and I preferred it much more strongly as an uncertain new editor; the "Preview" button was very reassuring. I suspect I'd never have hit "submit" without that reassurance. Keyboard shortcuts are nice, but they are not the first interface the new user sees. Honestly even a lot of experienced editors don't know they exit (I know they exist, but they don't work for me, not sure why).

Add apparently they are deprecated?[1] "Usage of access keys is currently discouraged in the online contents and applications". Because they conflict with screenreaders. This is daft. Wikipedia is, according to several vision-impaired people, pretty much inaccessible with most screenreaders, because instead of having a background tone or change in voice timbre for links, most screenreaders read the link targets aloud. Most WP articles have so many wikilinks that listening to them on such a system is insanely annoying. Even tech-savvy blind people often just do without rather than bother with it. WP needs an interface for vision-impaired users, and a related one for users with low or no literacy, especially as ownership of net-enabled phones by illiterate people increases. HLHJ (talk) 16:13, 5 September 2022 (UTC)

It looks like that was added in 2010 by Dodoïste. Looking at the whole section, it says that WCAG "abandoned" them and ATAG required them, and the editor believed that Wikipedia should comply with both. However, I'm not sure that's a complete description of WCAG back then; in particular, WCAG 2 was discouraging "character key shortcuts", which do not use any modifier keys. (The difference is whether you type Control+f or just f. If it's just f, then it's easy to accidentally trigger it.)

The 2010 summary looks out of date to me, since the current rules say that any HTML element may have an access key (which must use at least one modifier key, and normally follows the conventional modifier keys for that platform). Whatamidoing (WMF) (talk) 19:42, 1 October 2022 (UTC)

I've figured out why they weren't working for me, a clash with my attempts at multilingual typing configuration. Entirely on my computer, nothing to do with Mediawiki. I don't know enough to update that page, but I'll template it as out-of-date. HLHJ (talk) 23:53, 11 October 2022 (UTC)

Feature:Switch back to old editor

Tracked in Phabricator
Task T217857

Why do we not have a "old editor" option? VisualEditor and 2017 wikitext is nice but i would like to be able to switch back to the old editor at times. Erentar2002 (talk) 16:40, 7 March 2019 (UTC)

You can get an old wikitext editor (in between edits) by hand-editing the URL to say action=submit instead of action=edit or veaction=editsource (or similar bits).

I'm curious when you want an old wikitext editor. What's easier there? Whatamidoing (WMF) (talk) 18:33, 7 March 2019 (UTC)

Thanks for the info. Its not that the old editor is easier but it is more responsive and takes much less time to load compared to parsoid. The old editor still has some advantages. Nevertheless, the new editor is cool.(I would still like to see a ui buton for switching to the old editor) Erentar2002 (talk) 18:36, 7 March 2019 (UTC)

I filed the feature request. The theory is that switching modes while using the same toolbar should generally be faster than opening a different wikitext editor. However, on long/complex pages (or in particular circumstances; some people have old computers or poor internet connections), that might not be true. Whatamidoing (WMF) (talk) 18:41, 7 March 2019 (UTC)

Its not that the old editor is easier but it is more responsive and takes much less time to load compared to parsoid.

@Erentar2002 Thanks, what pages do you find take longer to load? In our analysis the new editor is quicker to load in over 80% of cases. Also the new editor doesn't really use Parsoid, except when you use some advanced tools from the toolbar. ESanders (WMF) (talk) 19:47, 11 March 2019 (UTC)

Bug when editing category pages

I have detected a bug. I cannot edit category pages when I click on edit code: the wikitext does not appear. To be able to edit it, I have to do a workaround: click on edit(visual mode) and then return to edit code and it works.

Ubuntu with Chrome 72 and Firefox 65. Paucabot (talk) 09:12, 8 March 2019 (UTC)

I can't reproduce on this wiki. Are you still having this problem? (Make sure that you have enabled the new wikitext mode in Special:Preferences#mw-prefsection-betafeatures and try editing Category:VisualEditor. You can revert any changes that you save.) Whatamidoing (WMF) (talk) 20:17, 15 April 2019 (UTC)

It seems it works now in both browsers. Thanks, Whatamidoing (WMF). Paucabot (talk) 05:23, 16 April 2019 (UTC)

Special characters menu

I'm not able to find the menu to insert special characters that used to be at the bottom of the old wikisource editor. Does anyone know this feature is there? If not, will it be added? Sjschen (talk) 02:42, 19 March 2019 (UTC)

CharInsert (sometimes called "Edit tools") is not supported. I don't think that the team is planning to support it. Which codes do you need it for? Whatamidoing (WMF) (talk) 02:07, 8 April 2019 (UTC)

Latin accented vowels. Always useful to have that around and would be sad to see it go. Sjschen (talk) 04:23, 12 April 2019 (UTC)

A special characters tool built in to the visual editor's toolbar. Look for an icon that looks like Ω next to the Insert menu. Whatamidoing (WMF) (talk) 16:38, 12 April 2019 (UTC)

Feature: VisualEditor's text editing mode intentionally does not encourage null edits

The current version does not allow null edits. Is this intentional? Thank you. -BRAINULATOR9 (TALK) 21:11, 20 March 2019 (UTC)

Yes, "null edits" shouldn't ever be needed. Jdforrester (WMF) (talk) 23:36, 20 March 2019 (UTC)

wikipedia:Wikipedia:Purge#Null edit

Apparently, there are reasons to do so. -BRAINULATOR9 (TALK) 23:39, 20 March 2019 (UTC)

We use'em all the time. IKhitron (talk) 01:34, 21 March 2019 (UTC)

The instruction from the Performance team is to file a bug if you find a situation where you think you need a null edit. Jdforrester (WMF) (talk) 18:07, 21 March 2019 (UTC)

Done title changed to officially list this as a bug report on the official 2017 wikitext editor/Feedback page. Alsee (talk) 18:20, 21 March 2019 (UTC)

I wasn't necessarily reporting it as a bug, though, just asking to clarify if that was an intentional design choice. -BRAINULATOR9 (TALK) 18:31, 21 March 2019 (UTC)

You are kidding? IKhitron (talk) 18:12, 21 March 2019 (UTC)

@IKhitron, I could be mistaken, but I believe JDF is the one primarily responsible for accepting/rejecting issues in this area. For example the lack of a directly accessible preview button, dysfunctional CTRL-V paste paste behavior, faulty previews, etc etc etc. Alsee (talk) 18:25, 21 March 2019 (UTC)

You are mistaken, in this and other things. Jdforrester (WMF) (talk) 18:32, 21 March 2019 (UTC)

It seems we have a lot in common. Alsee (talk) 18:37, 21 March 2019 (UTC)

Absolutely. I'm talking about null edits. IKhitron (talk) 18:26, 21 March 2019 (UTC)

You can make a null edit in the 2017WTE:

1. Open the page
2. Make any change (e.g., type one space).
3. Undo that change (must be done exactly).
4. Click the big blue button.
5. Don't add an edit summary.
6. Click the big blue button.
7. (Optional: Get a warning that you didn't add an edit summary, and click the big blue button again.)

In the older wikitext editors, steps 2 and 3 would not be needed.

Alternatively, you can hand-edit the URL to change &veaction=editsource or equivalent to &action=submit and drop into an older wikitext editor to do this.
Whatamidoing (WMF) (talk) 02:10, 8 April 2019 (UTC)

Some general thoughts about the new editor

I did some editing with the new editor, and wanted to list my pros, cons, and feature requests:

Pros

• Feels fairly quick
• It's nice that I can easily switch back and forth between previews and drafts pretty quick
• I like having auto syntax highlighting
• I like the template tool as well

Cons

• The auto-syntax highlighting is a little too light, would be nice if it was a bit darker
• Have to agree with others that the UI needs to offer more hints about how to get to the previews - it was very confusing for a while
• In the old text editor, adding an edit summary and then hitting "Preview" retained the edit summary for when you were ready to publish. The new text editor does not retain the edit summary, but it would be nice if it did
• I am an avid user of the ProveIt gadget, but it's not available for the new editor. It would be great if I could use ProveIt with the new editor. I'd like to advocate here for this grant to integrate ProveIt into the new editor to be funded

Feature Requests/Questions

• For the template tool - it would be nice if I could insert multiple templates at once, and if the tool let you fill out parameters like the one for the legacy wikitext editor allows you to do
• WikEd allows you to follow links with a ctrl-click, which is very useful, is the team is planning to implement this, or is there any plan to integrate WikEd with the new editor?

Thanks -Furicorn (talk) 22:40, 25 March 2019 (UTC)

Thanks for your feedback.

The new text editor does not retain the edit summary

Can you explain what you mean by this? If you open the edit summary dialog, then close and re-open it your edit summary should still be there... ESanders (WMF) (talk) 14:00, 26 March 2019 (UTC)

I went back to see if I could reproduce the behavior. Looks like it's retaining the edit summary now when I switch back from preview and resume editing, so it must've been something weird, or just user error. Furicorn (talk) 15:27, 26 March 2019 (UTC)

I'm not sure if I agree this is closed. Are there Phabricator (or whatever tracks progress for this editor) tickets for any of the following:

1. Changing level of auto syntax highlighting
2. UI changes to make it clearer how to reach previews
3. Being able to insert multiple templates at once using the template tool
4. WikEd integration (or at least "ctrl-click" functionality to follow wikilinks while editing)

If not, I would appreciate an explanation as to why. Furicorn (talk) 19:52, 27 March 2019 (UTC)

1. Already done: See m:Community Tech/Wikitext editor syntax highlighting#Color and style customization
2. phab:T153306
3. Already done: Insert the first template and then click "Show options" to reach the complex transclusion tool.
4. phab:T221029 Whatamidoing (WMF) (talk) 20:26, 15 April 2019 (UTC)

Bugs

• Writing no-break spaces in the new editor doesn’t work. I get usual spaces when I type a no-break space. No-break spaces do work in other MediaWiki editors, including the previous wikitext editor and the translation tool which is used on MediaWiki.org and Meta. No-break spaces can be typed with some keyboard layouts including mine (Bépo, which is a Dvorak-like for French; also the fr-oss layout with AltGr-Shift-Space). We can still use the HTML entity   but in my case it’s harder to write, and it makes the code uglier.
• On some pages on fr.wikiversity (example of such a page), the cursor is not at the right place, it is shifted. To make editing comfortable, I have to open the browser inspector and edit manually the .ve-init-mw-desktopArticleTarget .ve-ui-mwWikitextSurface .ve-ce-attachedRootNode rule so that it has the same padding as the .ve-init-mw-desktopArticleTarget .CodeMirror rule.

Thank you for reading and dealing with it. Frigory (talk) 11:50, 27 March 2019 (UTC)

• This request is documented at phab:T53045.
• Are you using a monospace font for editing? Using a variable-width font (like Times or Arial) causes problems with the CodeMirror syntax highlighting tool.

Whatamidoing (WMF) (talk) 20:28, 15 April 2019 (UTC)

• No it’s not. This request talks about creating a shortcut to insert no-break spaces. I’m talking about allowing to write no-break spaces when your keyboard layout already allows you to write no-break spaces. What I’m talking about is something that works with the most stupid text editor you can have. What is asked for on phab:T53045 is an advanced feature you usually have on a word processor which is usually quite an important piece of software. To my mind you shouldn’t deal with phab:T53045 but you should deal with my request. No-break space is a special character among many others; if you want to type one you should either have it on your keyboard layout (like me) or find it in a character table. However, whereas many important keyboard layout don’t offer the no-break space, it might still be important to type no-break spaces in formatted texts, but for the French case, MediaWiki already puts no-break spaces in the most important places (notably before colons and semicolons). But currently it’s simply not possible to type a no-break space even if you have it on your keyboard layout, and it’s pretty weird. It is not a feature request but actually a bug.
• Yes, I am using a monospace font. Sorry, my link was wrong, it should have leaded to fr.wikiversity (I’ve just fixed it). There’s a rule: .ve-init-mw-desktopArticleTarget .ve-ui-mwWikitextSurface .ve-ce-attachedRootNode { padding: 0 1.8em; } for the colored text. And e.g. here there’s a rule .skin-vector .ve-init-mw-desktopArticleTarget .CodeMirror { padding: 0 1.8em; } for the code editor, so things are OK. But here, the latter rule is not present, so it fallbacks to .ve-init-mw-desktopArticleTarget .CodeMirror { padding: 1.5em; }, which is different from the first rule and makes the text field shifted from the text display. I believe there’s a stylesheet structure problem. It might be quite specific to fr.wikiversity, but well, then you should probably inform the wikis or check for this yourself. Frigory (talk) 20:30, 16 April 2019 (UTC)

I also have another bug.

• Copy-pasting with middle click (on Linux) don’t work in the new editor (nor in the visual editor). I use this feature extensively… Currently on Firefox it pops a navigation tool (that thing which allows you to scroll the page by placing your mouse on the right side of it), and after the first click it does a copy-pasting but without moving the cursor, while usually this moves the cursor to the location on which you click. There’s much chance it’s already documented on Phabricator. Frigory (talk) 22:19, 16 April 2019 (UTC)

The inability to copy–paste with middle click on Linux looks like another CodeMirror problem: phab:T174635. Whatamidoing (WMF) (talk) 22:08, 22 April 2019 (UTC)

When they add the ability to insert a non-breaking space, they'll obviously have to start accepting them. That said, so long as enwiki tells people not to use 'invisible' non-breaking spaces, and therefore WikEd (a volunteer-supported editing environment preferred by some power users) keeps replacing them with the HTML code for non-breaking spaces, I wouldn't be surprised if the result was VisualEditor substituting the HTML code for non-breaking spaces rather than just leaving the actual non-breaking space in the wikitext (which is what I would personally prefer). Whatamidoing (WMF) (talk) 22:11, 22 April 2019 (UTC)

Adding no-break spaces through a special feature and through the ‘generic’ way (that works everywhere else on the system) is actually a different thing. You might be right, but I don’t think so; in any case, it’s not ‘obvious’. The editor is probably already able to edit pages that already contain no-break spaces, otherwise it would break things. If you add a way to add no-break spaces, it won’t certainly fix my bug.

Indeed   works in the wikitext editor, therefore I agree it’s not really an important feature to be able to insert no-break spaces with the wikitext editor. I didn’t even noticed that the Phabricator task you linked was about the VisualEditor… But   might be a too ugly syntax. Sometimes you might prefer to write no-break spaces directly in the code because it makes it more readable, and people should now that they have to write a no-break space at this place.

I’ll involve in the Phabricator task.

Thank you for your answer about the copy-pasting bug; indeed I’d already encountered it with CodeMirror. Frigory (talk) 20:37, 23 April 2019 (UTC)

VisualEditor is both "the visual editor" and "the new wikitext mode" (aka 2017 wikitext editor).

Whatamidoing (WMF) (talk) 20:43, 23 April 2019 (UTC)

OK. Thanks. Frigory (talk) 20:48, 23 April 2019 (UTC)

Raw/visual editor

I was expecting that this editor would change the visual editor and not the raw wikitext editor. Also I find that this new editor does not provide and apparent immediate ability to view the text as it would appear. It requires pressing the "offentliggør ændringer..." (publish changes) where the preview button appears. Fnielsen (talk) 15:54, 7 April 2019 (UTC)

Did you want to have two wikitext editors ("Edit wikitext with old tool" and "Edit wikitext with new tool")?

I think that quicker access to the Preview button is the most popular request for this wikitext editing mode. In the meantime, learning the Keyboard shortcuts (the same for all wikitext editors) may save you some time. Whatamidoing (WMF) (talk) 02:05, 8 April 2019 (UTC)

Hotlinked images, img tags, and previews

Tracked in Phabricator
Task T221684

Previews don't render hotlinked images and images using HTML img tags. This has caused confusion on wikis with $wgAllowImageTag and $wgEnableImageWhitelist set to true. See https://phabricator.miraheze.org/T4316#82239. Idrisz19 (talk) 02:39, 23 April 2019 (UTC)

Thank you for bringing this issue to Wikimedia's Phabricator, Whatamidoing. Idrisz19 (talk) 01:21, 24 April 2019 (UTC)

Cannot use preview

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

User agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:66.0) Gecko/20100101 Firefox/66.0

When I try to open a preview window, it loads forever without showing anything, and a “TypeError: titleAndFragment is null” appears in the web console.

I know this editor doesn’t officially support translatable pages, but what am I supposed to do? Disable the beta feature every time I want to edit one? I can’t find a way to load the old wikitext editor when necessary.

URL: https://www.wikidata.org/wiki/Help:Property_constraints_portal/One_of?action=edit Lucas Werkmeister (WMDE) (talk) 16:00, 25 April 2019 (UTC)

I'm sorry that you've encountered this serious limitation so often. I leave the 2017 wikitext mode disabled at Meta for exactly that reason.

As a workaround, you can hand-edit the URL to say action=submit (instead of action=edit or veaction=editsource). The "submit" action isn't valid for the 2017WTE, so it will switch you to an older wikitext editor. I have generally found that's faster and less annoying (for me) than constantly changing the prefs. Whatamidoing (WMF) (talk) 19:52, 25 April 2019 (UTC)

Thanks, action=submit is enough to solve my problem for now. Let’s just hope I remember it next time I run into this :) Lucas Werkmeister (WMDE) (talk) 09:22, 26 April 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Hard load and writing

It is very hard to rewrite text, and it loads slow like Visual Editor. ARychlik (talk) 11:55, 2 May 2019 (UTC)

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

Can you tell me more about problems with re-writing text? Whatamidoing (WMF) (talk) 15:07, 3 May 2019 (UTC)

Edit summary preview not working

Tracked in Phabricator
Task T223191

The edit summary preview doesn't work. It just shows the placeholder $1. Hmxhmx (talk) 09:40, 11 May 2019 (UTC)

Bad performance and more steps

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. Uziel302 (talk) 06:31, 17 May 2019 (UTC)

I also feel this problem. This problem occurs due to load of traffic while editing. Besthomefurniturebrands (talk) 07:49, 26 June 2019 (UTC)

Copying makes the visible and edited text inconsistent

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. —Aron Man.🍂 edits🌾 23:55, 29 May 2019 (UTC)

On Wikipedia, or in this message system? Whatamidoing (WMF) (talk) 21:56, 31 May 2019 (UTC)

^{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 —Aron Man.🍂 edits🌾 17:32, 3 June 2019 (UTC)

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. —Aron Man.🍂 edits🌾 17:59, 3 June 2019 (UTC)

Test paste link to visual: From WP:KB: on Windows, Chrome hold Alt+⇧ Shift or Alt+Control+⇧ Shift or Alt —Aron Man.🍂 edits🌾 18:02, 3 June 2019 (UTC)

Test paste link to source: From WP:KB: on Windows, Chrome hold Alt+⇧ Shift or Alt+Control+⇧ Shift or Alt —Aron Man.🍂 edits🌾 18:03, 3 June 2019 (UTC)

Test paste source markup to source: From WP:KB: on Windows, Chrome hold Alt+⇧ Shift or Alt+Control+⇧ Shift or Alt —Aron Man.🍂 edits🌾 18:04, 3 June 2019 (UTC)

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}} —Aron Man.🍂 edits🌾 18:04, 3 June 2019 (UTC)

Test paste link from visual editor to visual editor:

—Aron Man.🍂 edits🌾 18:07, 3 June 2019 (UTC)

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. —Aron Man.🍂 edits🌾 18:12, 3 June 2019 (UTC)

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. —Aron Man.🍂 edits🌾 18:13, 3 June 2019 (UTC)

Pasting from notepad: —Aron Man.🍂 edits🌾 18:14, 3 June 2019 (UTC)

Try again: —Aron Man.🍂 edits🌾 18:14, 3 June 2019 (UTC)

From notepad to source editor: —Aron Man.🍂 edits🌾 18:20, 3 June 2019 (UTC)

Paste from rendered html

From notepad: —Aron Man.🍂 edits🌾 18:21, 3 June 2019 (UTC)

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"> —Aron Man.🍂 edits🌾 18:24, 3 June 2019 (UTC)

Note: this thread wastes a lot of space, and should be removed or archived once this is fixed. —Aron Man.🍂 edits🌾 18:28, 3 June 2019 (UTC)

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. Whatamidoing (WMF) (talk) 18:08, 4 June 2019 (UTC)

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.

—Aron Man.🍂 edits🌾 19:03, 4 June 2019 (UTC)

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 <syntaxhighlight lang='text'> tags (the wikitext and HTML code) to trigger a window that will let you paste in whatever fragments of code you want to discuss. Whatamidoing (WMF) (talk) 01:24, 23 August 2019 (UTC)

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. —Aron Man.🍂 edits🌾 22:57, 20 September 2019 (UTC)

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). —Aron Man.🍂 edits🌾 23:02, 20 September 2019 (UTC)

Test: Aron Manning (talkcontribs)

Works well. —Aron Man.🍂 edits🌾 23:03, 20 September 2019 (UTC)

The Flow message-board is great!

^{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.

—Aron Man.🍂 edits🌾 19:22, 3 June 2019 (UTC)

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. —Aron Man.🍂 edits🌾 19:55, 3 June 2019 (UTC)

@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. Whatamidoing (WMF) (talk) 18:13, 4 June 2019 (UTC)

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. Jorm (talk) 18:19, 4 June 2019 (UTC)

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. —Aron Man.🍂 edits🌾 19:15, 4 June 2019 (UTC)

Arrow navigation skips blank lines

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. Cagliost (talk) 09:47, 15 June 2019 (UTC)

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. Jdforrester (WMF) (talk) 15:23, 18 June 2019 (UTC)

What this editor need to be useful for template/module developers

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. MarMi wiki (talk) 19:30, 17 June 2019 (UTC)

Why would you want to use this editor, instead of the Extension:CodeEditor, in the Module: namespace? Whatamidoing (WMF) (talk) 19:30, 20 June 2019 (UTC)

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). MarMi wiki (talk) 22:19, 20 June 2019 (UTC)

Fails for me

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. Piotrus (talk) 04:15, 25 June 2019 (UTC)

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. Idrisz19 (talk) 14:50, 11 July 2019 (UTC)

The design theory is that nothing moves around in the toolbar. Some things might be grayed out/disabled, but nothing changes places. This means that once you know where to find it, you always know where it is.

That idea is from 2012 (approximately?), so perhaps it's due for reconsideration. Whatamidoing (WMF) (talk) 01:29, 23 August 2019 (UTC)

NWE-CodeMirror-Timeless bug

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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

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. Idrisz19 (talk) 16:20, 11 July 2019 (UTC)

Timeless is a volunteer-supported skin. @Isarra, are these problems between Timeless and CodeMirror already in documented in Phab:? Whatamidoing (WMF) (talk) 01:42, 23 August 2019 (UTC)

Okay, the issue has been solved. Idrisz19 (talk) 17:16, 28 August 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

Incorrect PgUp/PgDn handling

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. Hdfan2 (talk) 03:51, 25 July 2019 (UTC)

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. Whatamidoing (WMF) (talk) 17:49, 28 August 2019 (UTC)
4. 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.
5. Ok. Though I'd like an option to make them smaller (on 27 4k monitor with 200% scaling they look huge)
6. Still don't see it. I have Save and View changes (diff) buttons, no preview. Alt+Shift+P does nothing. Hdfan2 (talk) 03:26, 29 August 2019 (UTC)
7. I can reproduce this in FF, so have filed as T231988. (This appears to be a bug in Firefox)
8. 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.
9. I can see the show preview in all browsers, are you sure you are in wikitext mode, and not visual mode? ESanders (WMF) (talk) 12:19, 4 September 2019 (UTC)

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). MarMi wiki (talk) 00:44, 30 December 2019 (UTC)

Firefox Copy/Paste white text

The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.

---

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. Dimon4ezzz (talk) 14:21, 17 August 2019 (UTC)

Does this happen if you "Paste and Match Style"? Whatamidoing (WMF) (talk) 19:49, 26 August 2019 (UTC)

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. Dimon4ezzz (talk) 17:19, 27 August 2019 (UTC)

I'm so sorry. This bug is only on my profile. I guess, I have some breaking extensions. Dimon4ezzz (talk) 16:50, 28 August 2019 (UTC)

The discussion above is closed. Please do not modify it. No further edits should be made to this discussion.

First impressions

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. Pelagic (talk) 11:05, 29 August 2019 (UTC)

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 2017 wikitext editor/Feedback/2019#h-NWE-CodeMirror-Timeless_bug-2019-07-11T16:20:00.000Z below. Pelagic (talk) 12:39, 29 August 2019 (UTC)

(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. Whatamidoing (WMF) (talk) 20:10, 13 September 2019 (UTC)

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? Pelagic (talk) 03:36, 14 September 2019 (UTC)

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. Pelagic (talk) 21:50, 29 August 2019 (UTC)

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. Whatamidoing (WMF) (talk) 20:06, 13 September 2019 (UTC)

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. Pelagic (talk) 04:16, 14 September 2019 (UTC)

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? Pelagic (talk) 04:45, 14 September 2019 (UTC)

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. Whatamidoing (WMF) (talk) 03:19, 15 September 2019 (UTC)

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. Pelagic (talk) 03:50, 21 September 2019 (UTC)

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. Kfogel (talk) 01:57, 31 October 2019 (UTC)

Integration for User Scripts

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. ESanders (WMF) (talk) 12:10, 4 September 2019 (UTC)

Load editor in background when new opened in new tab

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. Newslinger (talk) 21:38, 31 August 2019 (UTC)

Sadly this is a decision made by your browser, and we can do nothing about it. Jdforrester (WMF) (talk) 17:32, 3 September 2019 (UTC)

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. ESanders (WMF) (talk) 12:04, 4 September 2019 (UTC)

Thank you for the explanation! Newslinger (talk) 00:59, 5 September 2019 (UTC)

Colour of links inside of links

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. BrandonXLF (talk) 05:02, 5 September 2019 (UTC)

Editor is unusable after a table is inserted

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. BrandonXLF (talk) 05:09, 5 September 2019 (UTC)

Przy każdym haśle mamy na początku tabelę z treścią a obok puste miejsce. Przy większych artykułach jest to strata miejsca, nie mówiąc o estetyce. Składnia html nie działa. Jak więc przenieść tekst obok ramki ze spisem treści?

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 A.Domaszewicz (talk) 08:55, 14 September 2019 (UTC)

چطور عکس کاربر را کنا بیو گرافی آپلود کنیم

رابط کاربر: 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 Hassan Agha Seyed Abolghasem (talk) 19:41, 9 October 2019 (UTC)

بارگذاری عکس

رابط کاربر: 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

در هنگام ویرایش متنی جعبه ابزار نمایش داده نمی شود. نمیتوانم عکس را بارگذاری کنم Farnamk (talk) 09:36, 21 October 2019 (UTC)

Some impressions

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 Piramidion (talk) 10:19, 2 November 2019 (UTC)

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? Jaax (talk) 11:54, 20 December 2019 (UTC)

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. Whatamidoing (WMF) (talk) 22:06, 27 December 2019 (UTC)

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. Piramidion (talk) 22:52, 27 December 2019 (UTC)

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 ;-) Jaax (talk) 16:32, 28 December 2019 (UTC)

Significant problem

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 (talk) 23:19, 10 November 2019 (UTC)

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. Whatamidoing (WMF) (talk) 22:02, 27 December 2019 (UTC)

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) Ailbeve (talk) 22:27, 27 December 2019 (UTC)

Does this happen if you turn the syntax highlighting off?

Whatamidoing (WMF) (talk) 00:45, 28 December 2019 (UTC)

Bug when creating redirects

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. Jaax (talk) 16:28, 24 November 2019 (UTC)

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. ESanders (WMF) (talk) 12:15, 17 December 2019 (UTC)

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. Jaax (talk) 11:03, 18 December 2019 (UTC)

Okay, I see what happend. The "create page"-link opens the visual editor. Geez, Wikipedia never stops surprising me. Jaax (talk) 11:08, 18 December 2019 (UTC)

I miss the signature button

Tracked in Phabricator
Task T267227

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 ;-) Jaax (talk) 16:31, 24 November 2019 (UTC)

The signature is in the "Insert" menu, about four items from the end. Whatamidoing (WMF) (talk) 04:57, 13 December 2019 (UTC)

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. Jaax (talk) 11:51, 20 December 2019 (UTC)

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. Whatamidoing (WMF) (talk) 21:42, 27 December 2019 (UTC)

You might also be interested in the Talk pages project/replying tool, which automatically adds the signature for you. Whatamidoing (WMF) (talk) 21:44, 27 December 2019 (UTC)

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. Jaax (talk) 16:35, 28 December 2019 (UTC)

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 Jdforrester (WMF) (talk) 22:50, 6 January 2020 (UTC)

Ne serait-ce pas plus simple de faire une barre d'outil légèrement différente quand on est sur un espace de discussion où là, le bouton « Sourcer » ("Cite" en anglais) ne sert à rien car on n'insère presque jamais de références en discussion ? -- Nemo ^Discuter 17:40, 2 March 2020 (UTC)

I used citoid on a talk page two days ago.[2] Whatamidoing (WMF) (talk) 20:04, 2 March 2020 (UTC)

@Whatamidoing (WMF) En tous cas, il me semble que signer un message se fait à chaque fois tandis qu'insérer une référence ne se fait que de temps à autre (et on peut mettre le bouton Sourcer à la place du bouton actuel pour signer donc dans "Insérer".

C'est ce qui se fait déjà avec le vieil éditeur de wikicode actuel (le bouton signer apparaît à la place de sourcer en pdd), donc ça me paraît logique de faire pareil ici. -- Nemo ^Discuter 16:12, 3 March 2020 (UTC)