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
Text is available under the Creative Commons Attribution-ShareAlike License; additional terms may apply. See Terms of Use for details.
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.
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:
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
Sure, it's 2019 and we're talking about the 2017 editor, so apologies for being late to the party.
I do hope that dev time can be devoted to getting this editor out of beta, as it shows promise. A consistent toolbar might be appreciated by some of those who toggle often between visual and source modes(?). Just please please don't make it the only choice nor stop maintaining the old editors.
That's a lot of dot points – as I got carried away by detail – so, to summarise, my Big 3 areas for improvement would be: (1) flow of preview–diff–summarise–publish, (2) syntax highlighting, (3) preserve state against loss.
But I just realised (2) might be for Timeless only? Per Topic:V3ap9inic4lnhfim below.
(2) is probably for Timeless only, and (3) is handled with a (silent) auto-save feature. You might lose a little bit, but you shouldn't normally lose everything.
Second impressions
Tried just now with Safari, iOS 9.3.5, Vector skin, "desktop site", 9.x-inch Retina display, iPad 3, touch only (no Bluetooth kbd).
Just a quick test: deleted one word, tapped around the toolbar and publish-changes-related screens.
UI still fairly responsive. Feels just a teeny bit slow, but no worse than many sites on this older device. Only exception is the symbols list (omega button) takes a very long time to show.
I see now that you can already flip between Review your changes and Preview screens (dialogs, modes, views, overlays, whatever is the correct term). The relationship between these two screens and Save your changes makes more sense now.
I can see how people might want to publish directly from the diff or preview screens, but still think there is value in having them return to Save your changes before publishing. At the cost of a single click, it means they get a second chance to see the legal copyright note, and to consider their edit summary.
Perhaps the initial "Publish changes ..." button with ellipses could be renamed to "Review and publish..." to reflect its full function and distinguish it more from the second "Publish changes" button. I do notice on the smaller screen there is less free space on the toolbar to accommodate a second button.
Multi-line selection with syntax highlighting turned on works fine with Vector skin.
Bug? Can't paste into Edit Summary box on this platform.
Did the non-pasting Edit summary contain any sort of formatting (e.g., links or images)? There are some things that it won't let you paste because it can't make sense of them. In that instance, "Paste and match style" (or whatever system the web browser has for pasting unformatted text) usually works.
On further testing, it appears to depend where I copied from. More like a VE copying problem than a pasting problem. Will need to check some more platforms. If this only happens on old iOS versions then there's less reason to fix.
With Safari on iOS, I don't have an option to paste as plain text (I do love Ctrl+Shft+V on desktop Firefox!).
Procedure I'm following is: tap in the text field (edit summary) to activate it; tap at the cursor to activate context menu; observe whether menu says "Select | Select All" or "Select | Select All | Paste".
Desktop view: if I copy some words from 2017 wikitext editing mode or from visual mode, they are not pastable into the edit summary. Text from an external application like Notepad is pastable. For what it's worth, I can't paste the same copied text (from 2017 source mode) into this SD-editing box either. If I try to paste it into Notepad, there is a paste option but no content is inserted.
Mobile view: if I copy text from wikitext editing mode it is pastable, but if I copy the same text from visual editing mode it isn't.
Oh ha ha ha face palm.
On iOS 12 Safari, the VE toolbar gives me a warning alert that I am “using a browser which is not officially supported by this editor”. And yet copying works there.
iOS 9 Safari, no alert but copying doesn't work.
We can probably Let It Go … or maybe Let It Be? The user base of older devices shouldn't be ignored if we want to reach people in rural, impoverished, and international situations (or maybe you have user-agent stats saying it's not that important?). But iOS is served primarily by the mobile view and we don't need every editor to work perfectly on every platform.
@Whatamidoing (WMF): Could somebody list this somewhere for the record as "known issue won't fix", if that's appropriate?
Rural and impoverished situations probably aren't using iOS anything. They're probably using Android.
Does phab:T190291 look like this problem? I'm going to put a link to this discussion there.
Yes, that's exactly it, Whatamidoing. And Belezzasolo described it more succinctly than I could. Thanks for adding the comment to that task.
Good point about Android.
I just want to echo Pelagic's comment about the very confusing Preview flow. I tried as hard as I could to predict what would happen when I pressed "Publish" again while in Preview mode, but it still didn't do what I expected (i.e., it didn't do what had happened when I'd pressed an identical-looking "Publish" button just moments before to get into Preview mode in the first place). As a result, I ended up accidentally publishing this change without the edit summary that I had intended to give it.
URL: https://fa.wikipedia.org/wiki/%D8%AB%D9%85%DB%8C%D9%86_%D8%B3%D8%A7%D9%84%DA%A9?action=edit
در هنگام ویرایش متنی جعبه ابزار نمایش داده نمی شود. نمیتوانم عکس را بارگذاری کنم
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.
In the Flow "structured discussion" editor, which I did not distinguish from the Visual Editor, as they are quite similar.
Right here. I guess there's an internal state for the editor that is not updated with the pasted content, as it is visible, but not saved. Chrome on Win
This seems to have improved from last time, pasting from source editor to source editor now works, with markup, formatting, links all preserved.
Pasting formatted text, links, html content will show up with the formatting in ***both*** source and visual editor, but changing to and back between editors reveals that only the text remains, all markup is stripped.
I believe the expected behaviour is: pasting to source editor shows the markup (source) of the pasted content, and pasting to visual editor retains the markup, while showing the formatted (visual) result. Will do some more tests.
Test paste link to visual: From WP:KB: on Windows, Chrome hold Alt+⇧ Shift or Alt+Control+⇧ Shift or Alt
Test paste link to source: From WP:KB: on Windows, Chrome hold Alt+⇧ Shift or Alt+Control+⇧ Shift or Alt
Test paste source markup to source: From WP:KB: on Windows, Chrome hold Alt+⇧ Shift or Alt+Control+⇧ Shift or Alt
Test paste source markup to visual: From [https://en.wikipedia.org/wiki/Wikipedia:Keyboard_shortcuts WP:KB]: on Windows, Chrome hold {{Key press|Alt|Shift}} or {{Key press|Alt|Control|Shift}} or {{Key press|Alt}}
Paste from visual editor to visual editor: From WP:KB: on Windows
Paste from rendered html to visual editor: From WP:KB: on Win, Chrome hold Altor Alt+⇧ Shiftor Alt+Control+⇧ Shift,
Copy-Paste simple text from this visual editor to itself: from rendered html to visual editor
Copy-Paste link from this vis editor to itself:
Note: At this point - after deselecting the link - the visible html widget was updated with the plain - no link - text.
Note 2: Pasting a link will add style="background-repeat: no-repeat, repeat; [... many background styles]" to the <A> element, repeating the tiny arrow behind the link text, making it unreadable. This is unnecessary, the .external style takes care of it. Just editing a previous message won't add inline style to the links.
This confirms: markup is stripped in both source and visual editor, but the proper, formatted html is show (in both), until the text is selected and deselected, when it is replaced with the plain stripped text.
Copying from source to source editor works properly.
Pasting from notepad is lost, see below.
It seems its pasted in the wrong element:
Yes, it's not wrapped in a <span class="ve-ce-branchNode ve-ce-contentBranchNode ve-ce-paragraphNode">
Note: this thread wastes a lot of space, and should be removed or archived once this is fixed.
Fixing the wikitext-to-wikitext-mode pasting problem requires dev time, and this tool isn't getting much attention right now. Certain kinds of wikitext get "sanitized" in this editing system before being saved.
These tests show the problem with sanitization is upon pasting the text. My first observations mentioned saving, but it happens earlier.
2. It's still not clear to me, how this flow-editor (both source and visual) are related to the standard wikitext editor (both source and visual). Is it the same software in some parts, or completely different? The design (toolbar icons) are the same, the only difference I see is a more extensive toolbar in wikitext editor.
The point of me asking this is: should I move this thread (the above Flow editor tests) to an appropriate Flow feedback talk page (which I did not find...)?
3. I saw the Flow was tested and rejected an enwiki. While I sense the community's unwillingness to change, the inability to copy-paste into chat would be a deal-breaker for me too. I'm interested how this and the ellipsis menu UX can be fixed.
The Flow (aka Structured Discussions) editor is sort of the visual editor, with a smaller toolbar. But it doesn't (currently) store the contents in wikitext, so if you give it wikitext or want to extract wikitext, then it runs the relevant parts of the database record through Parsoid to get wikitext. The differences between the two parsers is small and diminishing (eventually, the "two parser" problem will be solved by removing the old one and doing everything in wikitext), but there are a few quirks at the moment, including the fact that it "sanitizes" unbalanced HTML. So if, for example, you were to paste in part of a wikitext structure – maybe [[link or {{template – it may behave unexpectedly.
You can type <pre> tags (the wikitext and HTML code) to trigger a window that will let you paste in whatever fragments of code you want to discuss.
My test was to copy a link from the flow discussion in the web browser (thus html) to the editor. The resulting problem (the pasted content not wrapped in a span) could be observed without saving the message. That unwrapped content was ignored/trimmed by the conversion. I would assume the database was not involved in this process, otherwise editing would be very slow with a web request on each edit. I think this was a bug in the javascript implementation of the editor. Once I'll take the time and find the bug in the code, but now I only have the observation. Furthermore, I can't reproduce it atm. Maybe it has been fixed?
Thanks for introducing me to Parsoid, btw.
Seems to be fixed. Text is not wrapped in a <span> inside the <p> elements now. Text I paste into either VE or SE is kept and converted, when I switch to the other editor (both ways).
URL: https://pl.wikipedia.org/w/index.php?title=Puszcza_Bia%C5%82owieska§ion=0&veaction=editsource
https://phabricator.wikimedia.org/T212680, workaround is disabling syntax highlighting.
After doing some editing to a page. When you insert a table using Insert > Table, the editor basically becomes unusable. The editor is unusable as in when you try deleting or entering text on one line, the text is deleted or entered on another line. I originally posted this at Wikipedia:VisualEditor/Feedback on the English Wikipedia, but it makes more sense for it to be here. This has been going on for at least a few months now.
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...
[[File:example.png|thumb|This a caption with a [[link|display]], okay?]] should be...
[[File:example.png|thumb|This a caption with a [https://en.wikipedia.org external link.]]] should be...
[[File:example.png|thumb|This a caption with a [https://en.wikipedia.org external link], okay?]] should be...
[[File:example.png|thumb|This a caption with a [https://en.wikipedia.org], okay?]] should be...
I prefer option A and I'm fine with either option B or option C. I originally posted this at Wikipedia:VisualEditor/Feedback on the English Wikipedia, but it makes more sense for it to be here.
When I open the "Edit" link for a page in a new tab (in the background), the 2017 wikitext editor doesn't load until I switch to that tab. After switching to the tab, the editor takes another second or two to load, with the progress bar shown. Ideally, the editor should load in the background when it is opened in a new background tab, so users don't have to wait those extra seconds when they switch to the tab.
Sadly this is a decision made by your browser, and we can do nothing about it.
Assuming you are using Chrome, more information can be found here: https://developers.google.com/web/updates/2017/03/background_tabs, including instructions on how to disable this for yourself with a flag.
