@Aklapper I'm not sure how to handle this. T178735 was merged here because it addresses the same issue, but I disagree with the task being proposed here. This is task is defined as a child of Support global preferences. Should I alter the task tile & description to address the problem in general?

In T158474#3038300, @matmarex wrote:

My patch above only ensures that it's impossible to actually register that username and make real edits using it.

You can document its purpose on its user page, like it was done e.g. for https://de.wikipedia.org/wiki/Benutzer:Maintenance_script.

Note user:Unknown_user already existed on EnWiki (and only on EnWiki). It was created and briefly used for a few days in 2004. It has 126 edits. Any username should always be checked for existence before using it for any system purpose.

I believe the proper behavior (meaning the easiest to understand and most expected behavior) is to just protect the wrapped content then behave as if the <<< and >>> don't exist. This does a good job of covering most of the listed edge cases. For example:

{{foo |<<<You know someone's going to do >>> this at some point accidentally. What happens?}}

would be identical to

{{foo |You know someone's going to do  this at some point accidentally. What happens?}}

In T171027#3673060, @Lydia_Pintscher wrote:

This is a hugely political issue.

Many people experience this. Using Visual Editor for previews is often absurdly slow, upwards of a minute in some cases. From a UX perspective, there is little meaningful difference between:

1. freezing for over thirty seconds then successfully showing a preview;
2. freezing for over thirty hours then successfully showing a preview; or
3. freezing permanently.

As has already been demonstrated, running two parallel systems to track the same information is unreliable. And you acknowledge that more work would be needed (T131896) trying to fix the span method. Given that "Using the category is easy", I'm puzzled why you'd even bother advocating invisible, unreliable, duplicate, currently-broken method which needs repairs?

There have been a lot of objections to RelatedPages putting pseudo-random links on articles. Putting Islam on Misogyny, fascism on a politician, I think Pig-faced woman ended up on a woman's biography. It just put promotional links for two brands of tissue on the Facial_tissue article, and one of the links literally included an image of an advertisement for that brand. The WMF slapped an advertisement on the article. I'm just waiting for someone to find Pedophilia on someone's biography.

To staff/devs: Thanks for the quick fix here.

First, a huge thank you for working on showing moves in diff! YEAY!

Some of the comments above suggested treating article pages and talk pages differently. That's a mistake. A generic page should be presumed to contain both article content and discussions. Copying arbitrary article content to any page is a fundamental part of our work.

To put it more succinctly, I want a "mode" where the next&previous links are tied to the user rather than tied to the page. I just can't think of a good place or method in the interface to request that mode.

@Whatamidoing-WMF
I am admittedly stretching the limits of what I know about javascript, but it appears something like

textarea.on('input', ...

solves that issue. I'm unsure, but a little extra code may be needed to catch cut/paste via right click.

In T57370#3490603, @Whatamidoing-WMF wrote:

Because it isn't actually possible in the older wikitext editors.

Why is this described as a Visual Editor task? Visual Editor is a minor secondary editor, only used for a small percentage of edits. If auto save is implemented, it's certainly reasonable to also implement it in the secondary editor as well (VE).

It would be rare for someone to deliberately search for bad-faith likely-good edits, so this is not a major issue. Perhaps just display a message that the search may be slow.

The website vcard for the author contains an email wrapped in javascript protection. The javascript is getting copied as text, as if it's a list of additional authors. I'm not sure if the problem is on our end, or if their website is doing something invalid.

In T155732#3377259, @Frigory wrote:

In T155732#3377170, @Alsee wrote:

With the NewEditor it takes me over half a minute to preview United_States just once, and over five minutes staring at the blue VE-loading-bar if I want to jump between article-text and preview ten times.

Did you try Shift-Alt-P to see preview? This way it loads without the blue VE-loading-bar.

I was a little sloppy, preview shows moving gray stripes instead of a blue loading bar. It's the same problem though. Previews appear to be cached, so if you aren't actually editing then repeat previews "only" takes ~8 seconds (~4 seconds to switch ~4 seconds to switch back). However if you're actually working, each keypress kills the cache. A preview takes ~30-35 seconds to load, plus ~4 to switch back. So ten previews is over 6 minutes. Usually I just use one preview before saving, which is still an appalling and unusable performance. But yeah, sometimes we easily hit ten or more previews while working. Having preview on the same screen as the wikitext matters a lot.

Based on the video , it looks like the blue box was't fully covering the link. Hypothesis: If rendering of the blue box is delayed or the location is offset, the underlying link is exposed and clickable?

I did a little experimentation. It appears this bug is being triggered by T153315. Instead of doing a normal copy-paste, the NewEditor defaults to trying to convert HTML into wikitext. When it sees the italics it triggers HTML->Wikitext conversion. Then nowikis get spammed into your wikitext.

With the current editor it doesn't matter how long the article is. Everything is on one long screen. I simply highlight some unique text and use the browser search on it. Pressing F3 then jumps back and forth between article text and the matching wikitext.

Halibutt I'd welcome better data, but so far no one has been offering any. The community has abundant collective real-world experience, and I believe most people will find the available data to be sufficiently clear despite the imperfections.

@Deskana thank you for closing this. Prior to seeing you had closed this, I had also come to the conclusion that continued individual-debate here had become an unproductive time sink for everyone involved.

In T159032#3298832, @Deskana wrote:

In T159032#3293776, @Alsee wrote:

(Polish VE statistics)

Interesting. I would've expected that to be higher. Did you remove all the confounding factors when producing these statistics?

I listed the settings I used. I made a good faith effort to filter out confounding factors and maximize the VE percentage. Any other factors would only shift the results by a few points. The results are clear enough that fussing over a few percent won't alter the conclusions.

Adding report by JAn Dudík:
United States 75 sec.
List of planets 140 sec.

I just collected data using the Recent Changes page, set to display the last 5000 edits. Bot edits and logged actions filtered out.

In T144571#2650519, @Jdlrobson wrote:

if JavaScript fails to load... going to the file page will happen

Thank you for clearing up why some of the testing gave random results. However that is not directly related to this issue.

In T159032#3184818, @Halibutt wrote:

The WMF ran a controlled study on the effects of visual editor, showing that it provided zero benefit to new users and finding notable negative effects. Is there anyone here who honestly thinks that a majority of the general global editing community wants VE to be made the default?

Would love to see the study you mention, never heard of it.

Research:VisualEditor's_effect_on_newly_registered_editors/May_2015_study. Results: No change in how many new users made a first edit. No change in new user retention. No change in total contributions. Visual Editing was typically over 6.7 times slower, people were more likely to abandon edits without attempting to save, and attempted saves were less likely to be successful.

@Kipod, I strongly disagree.

This popup is a useless "click-to-continue" annoyance when it has only one option.

In T159032#3184069, @Halibutt wrote:

If you really want to start a format consensus process, use the main BAR rooms, not the technical room used mostly for bug reporting.

• Burying PREVIEW in a menu behind the SAVE button leaves new users lost and scared when they actively avoid touching the dangerous SAVE button.
• Burying the most used button in the editor is disruptive for experienced editors.

The most used button in the entire editor, and second most important button in the entire editor, absolutely warrants direct placement next to the SAVE button.

The discussion was unanimous when I posted it. Now one person has disagreed.

@Halibutt : While the comments were posted "last year", they are not over a year old. They were 3 months old when I opened this Phab, and now 4 months old. Your oppose and the new responses, it looks like 6-1. Would you like to open a more formal consensus-process to get a more formal result?

In T154844#3118613, @Jdforrester-WMF wrote:

can you clarify?

I updated the task description to reflect the closure of the RFC on this issue. Also, my understanding is that blocker tasks inherit the priority of the parent task.

I updated the task description to reflect the closure of the RFC on this issue. Also, my understanding is that blocker tasks inherit the priority of the parent task.

Note that the Minor Planets page has been split. Anyone wanting to test that load time should use the link in Samwalton9's post above.

@Jdforrester-WMF, it's been almost three weeks since I opened this bug. Can I get an answer on this?
You said VE wouldn't be imposed as the SingleEditTab default without asking the community. You said it was a bug that SingleEditTab was deployed with a VE default. EnWiki was fixed to wikitext default, per discussion with the community. And now PolishWiki has a unanimous consensus asking for SingleEditTab to have a wikitext default.

@jayvdb's suggestion looks like the best concepts here. I'd suggest a tweak:

I'll add another voice to the chorus saying that CTRL-V needs to be a plain text paste. The formatted paste behavior is disruptive.

In T99924#1550540, @Jdforrester-WMF wrote:

If we let you interact with a template, we let you edit it.

I don't think it's a good idea to start singling out arbitrary section titles. Any empty section is almost never a desired permanent state. However it's not that unusual for sections to be empty while an article is being built, or when it's awaiting content, or when there is a debate in progress on what should/shouldn't be there.

I know next to squat about databases, so I apologize if this is incredibly dumb or obvious. Would it help to: Create the new comment table as write-only, fill it at leisure, and switch all reads&writes to the new table after it fully mirrors the existing data? Then increase the comment limit and clean up the old unused data at leisure.
That at least avoids the need to check both places during reads.

The task is a four letter edit.

In T159032#3081337, @Jdforrester-WMF wrote:

Can you explain how this is different from T102398?

Can someone please provide some sort of a response here?

In T63729#3038137, @jeblad wrote:

<rant>Sometimes I would really want a more firm standpoint from WMF against people moving backwards… </rant>

@Jdlrobson: I definitely didn't assume any bad faith here, and I didn't mean to "blame" anyone in particular. Consider this my attempt to stir concepts into the idea sessions :)

Why edit in the page when you can edit outside it?

I'm going to re-open this. Based on a Google Translate view, it looks like there wasn't really any opportunity for them to comment on enablement of Hovercards. All I saw were comments indicating they couldn't comment on it because (at that time) testing of Hovercards was disabled.

@Aklapper I expanded the task in the description, and I see that this still hasn't been triaged.

In T7004#1605592, @Magioladitis wrote:

I don't really agree with this request. I prefer to see what is about to be saved.

Summary of load times reported at the RFC:
Alsee: United States 30 seconds. List of Planets 127 seconds.
Daß Wölf: List of planets 114 seconds. Village pump proposals 21 seconds.
Yodin: United States 35 seconds. List of planets 122 seconds.
Fram: Leuchtenberg Gallery 15 seconds. Exposition des primitifs flamands à Bruges 50 seconds.
Whatamidoing: United States 9 seconds. <--- One anomalous report

In T154843#2982245, @Whatamidoing-WMF wrote:

Alsee, are you running Windows?

Yes.

In T154843#2957459, @Whatamidoing-WMF wrote:

why your experience of performance is so different from other people's.

Holy crap. Wikidata should not be linking to our draft space at all. They definitely should not appear on other language wikis, as public links to a supposed English Language version of the article.

Rather than "assumptions", I'd rather call it a concern. Ensuring a good initial publication is a lot better than (possibly) trying to rewrite history after publication.

I'll illustrate the problem:

@Trizek-WMF thanx for the reply, although I think I failed to properly identify my concern. I fear that you may be unaware of a potential incoming trainwreck.

The RFC on Meta has closed with a clear consensus to remove Flow. Note that this was not an RFC to reduce active Flow pages to zero, this was an RFC for the extension be uninstalled as was done on Enwiki. (T148611)

Four months ago I commented here: The analysis needs to clearly note that invitation and participation were heavily biased towards Flow enthusiasts. (Invitations were selectively posted on the user_talk pages of the small minority who converted their user_talk to Flow.) This should be particularly noted in relation to the question comparing wikitext to Flow.

@Aklapper if you can get the this new editor load time to be comparable to current editor load times, then sure. That will get this Phab listing closed, and terminate the entire discussion here.

The issue was first raised by me 14 weeks ago half way down this thread on Talk:Wikimedia_Product. That was before any project page or documentation even existed yet. "Whatamidoing, can you please please please go to the head of the New Wikitext Editor project and tell them that a new "Wikitext editor" that doesn't have genuine wikitext support is a deal breaker? It has the same Parasoid-based fake wikitext that Flow has. I suspect there would be a consensus against even having it in Beta-features until that "bug" is fixed. I've already saved a screenshot showing the New Editor botching the preview in nine different ways at once, and it's not hard to show lots more. A new wikitext editor that can't give accurate previews is a non-starter."

To avoid a split discussion, see my Technical Collaboration Guideline comment at T154843#2926550.

P.S. I forgot to mention the Technical Collaboration Guideline. As an individual, I am proposing this as an Actionable Blocker. I would be more than happy to see the WMF close this as cantfix/wontfix, so long as it will be reopened as a blocker if/when the community formally resubmits it as a consensus blocker issue.

What I mean is that the community wasn't quibbling about the exact quantity of work. If you could wave a magic wand and reduce the labor by 90%, it wouldn't have made a difference. People who opposed it still would have opposed it.

@Aklapper I just had it happen again. I was able to get a screenshot this time:

I believe I have avoided a "blame" tone in my list below, but I welcome any attempt to improve tone or clarity.

• Pre-development input: This is an old lesson. Early community input has previously been identified as a key factor in the success or failure of a project. For some reason it is still hard to put this lesson into practice. The Gather project was effectively invisible to the community, up to the point it was announced for deployment. Community input during the concept and design phase could have identified significant issues in advance. The idea could have been re-thought, or cheaply canceled.
• Moderation tools: The community has fairly high expectations that any user-generated content is tracked in contribution history, that all of the usual functionality be available for cleaning it up, and that cleanup actions be logged for accountability. Integrating any new non-wikipage user content into our existing systems is a significant undertaking. It should not be done lightly. The community may (uncomfortably) accept bugs or limitations in theses systems in a limited beta-test. However a project team must be prepared to either roll back the product, or to take responsibility for implementing full tracking&moderation functionality if content is left live for an extended period. This issue was addressed by Risker's checklist for content-creation extensions and T126952: Integrate Risker's checklist for content-creation extensions to the WMF product development process.
• Was the maintenance burden underestimated? (Suggested in comment by @JEumerus.) I think it is important to note that this was NOT a significant focus in community discussions. Yes, there would be a lot to review, and yes AFD style keep/delete debates would be ugly, but the critical community concerns were not the what the WMF expected.
• Nature of the content and nature of the work: The content goes against many community policies, and against the very reason that we volunteer. Editors volunteer their unpaid labor to generate publicly-owned content, as a public service to the world. Even user space pages are considered community owned, they are (loosely) expected to serve our global-good mission. Gather content is viewed as essentially "privately owned" social-network style random junk. Any labor greater than zero is like being an unpaid employee policing Facebook content. The community isn't a free labor force to police John Doe's personal junk, for John Doe's personal benefit. The work might seem similar, but community sees a significant difference.
• Terminating a project must be explicitly in-scope for discussion: This issue lead to communication-breakdown and collaboration-breakdown on multiple levels. There were multiple requests from the community to the WMF for a collaborative process to resolve the issue. These requests were made to the liaison, to the project manager, and even to the executive director. All of those requests received evasive non-responses. (Is there some internal WMF policy or culture against responding to those requests?) Multiple requests were made for the WMF acknowledge that ending the project was in-scope for discussion. All of those requests received evasive non-responses. (Is there some internal WMF policy or culture against responding to those requests?) This issue eroded community trust that the WMF was willing or able to participate in good-faith collaborative resolution. It's hard to discuss fixing a project when the WMF can't acknowledge that ending the project might end up being the most appropriate outcome.
• "Community doesn't like/want a product" needs to be considered valid and important feedback. If the community reasons are unclear or confusing, the actionable-response is to investigate and engage. The WMF shouldn't have missed the huge red flag when the Administrator's Noticeboard announcement turned into outright revolt. The community may have communicated its position poorly. The community tends to cite policy-jargon in its reasons. And in this case the community discussion took an odd turn... the community didn't want to engage in an uphill battle arguing against the project. The community basically said "You can keep your project but you'll have to pay staff to do 100% of the labor". This was basically a sarcastic position. The community did not expect the WMF to pay staff to police the content. The WMF was expected to realize that the project was non-viable without community&admin support. In any case, the WMF should have taken the situation seriously.
• Avoid telling the community not to run an RFC. A number of editors wanted to pursue collaborative-resolution with the WMF. Morale for a collaborative process broke down for a number of reasons. Telling the community not to run an RFC is a sore point. This was a "last straw" that caused the final crumble in morale. At that point the community started the RFC, rather than wait for the WMF to announce its internal decision on Gather.

T154387 was just closed as a dupe of this because the general issue is being dealt with here, however T154387 is a much more specific bug with much more specific requirements.