Open main menu

2017 wikitext editor/Feedback

About this board

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 PhabricatorJoin the IRC channel

Ailbeve (talkcontribs)

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.


Reply to "Significant problem"
Piramidion (talkcontribs)

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

Reply to "Some impressions"

First impressions

11
Summary by Whatamidoing (WMF)
Pelagic (talkcontribs)

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 (talkcontribs)

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.

Whatamidoing (WMF) (talkcontribs)

(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.

Pelagic (talkcontribs)

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 (talkcontribs)

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.

Whatamidoing (WMF) (talkcontribs)

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.

Pelagic (talkcontribs)

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 (talkcontribs)

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?

Whatamidoing (WMF) (talkcontribs)

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.

Pelagic (talkcontribs)

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.

Kfogel (talkcontribs)

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.

Reply to "First impressions"
Farnamk (talkcontribs)
Reply to "بارگذاری عکس"

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

1
Hassan Agha Seyed Abolghasem (talkcontribs)
Reply to "چطور عکس کاربر را کنا بیو گرافی آپلود کنیم"

Copying makes the visible and edited text inconsistent

23
Aron Manning (talkcontribs)

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.

Whatamidoing (WMF) (talkcontribs)

On Wikipedia, or in this message system?

Aron Manning (talkcontribs)

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 Manning (talkcontribs)

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 Manning (talkcontribs)

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

Aron Manning (talkcontribs)

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

Aron Manning (talkcontribs)

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

Aron Manning (talkcontribs)

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 Manning (talkcontribs)

Test paste link from visual editor to visual editor:


Aron Manning (talkcontribs)

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 Manning (talkcontribs)

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 Manning (talkcontribs)

Pasting from notepad:

Aron Manning (talkcontribs)

Try again:

Aron Manning (talkcontribs)

From notepad to source editor:

Aron Manning (talkcontribs)

Paste from rendered html From notepad:

Aron Manning (talkcontribs)

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 Manning (talkcontribs)

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

Whatamidoing (WMF) (talkcontribs)

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.

Aron Manning (talkcontribs)

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.


Whatamidoing (WMF) (talkcontribs)

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.

Aron Manning (talkcontribs)

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 Manning (talkcontribs)

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 Manning (talkcontribs)
Reply to "Copying makes the visible and edited text inconsistent"

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?

1
A.Domaszewicz (talkcontribs)
Reply to "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?"

Editor is unusable after a table is inserted

1
Summary by 197.235.243.160

https://phabricator.wikimedia.org/T212680, workaround is disabling syntax highlighting.

BrandonXLF (talkcontribs)

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.

Reply to "Editor is unusable after a table is inserted"
BrandonXLF (talkcontribs)

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.

Reply to "Colour of links inside of links"

Load editor in background when new opened in new tab

4
Newslinger (talkcontribs)

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.

Jdforrester (WMF) (talkcontribs)

Sadly this is a decision made by your browser, and we can do nothing about it.

ESanders (WMF) (talkcontribs)
Newslinger (talkcontribs)

Thank you for the explanation!

Reply to "Load editor in background when new opened in new tab"