Hi @Johnywhy, thanks for taking the time to report this!
I assume this is about https://www.mediawiki.org/wiki/Project:Support_desk (links welcome that allow reproducing).
What are steps to reproduce, and which browser(s) and browser version(s) on which operating system(s) was this tested with?

i can't yet identify specific steps. It happened both while posting a new topic, and when replying to other comments.
So far, it has not happened on the first paragraph, only after the first paragraph.
I think it happened on hitting Enter key, but not sure if consistent.
All on Chrome browser on Windows 10.
Sorry for lack of detail!

I can't reproduce your issue, @Johnywhy. What happens precisely? How do you get that problem?

I described as well as I can. More info:

After paragraph disappeared, i hit CTRL-Z repeatedly, and you can see the result. Words started popping in without spaces. Maybe issue with undo buffer?

<Pre>UpdatenowgettingthesamebugonagberroronapagecontainingnoturlThebodyisnotexcessivelylongeither</pre>

(I don't know why <pre> doesn't work on mobile.)

I am afraid we need a list of steps, step by step, if/when you can reproduce this.

Steps:

1. Sign in to MediaWiki.org

2 Browse to support desk.

Scenario 1:

1. Enter title for new topic.
2. Enter paragraph of body text.
3. Enter 2nd paragraph of body text.
4. Enter 3rd paragraph of body text. During entry of 3rd paragraph, 2nd paragraph suddenly vanishes.

Scenario 2:

1. Click "Reply" on an existing comment.
2. Enter paragraph of body text.
3. Enter 2nd paragraph of body text.
4. Enter 3rd paragraph of body text. During entry of 3rd paragraph, 2nd paragraph suddenly vanishes.
5. Press Ctrl-Z repeatedly
6. The lost para reappearsi, word for word, no spaces.

Cannot reproduce any of the scenarios in Firefox 59.

Does that also happen in other web browsers?
Does that also happen in a fresh, clean browser profile, with all add-ons and extensions disabled?

I do not expect a bug in Wikimedia code here but something wrong on the user's system...

I can't reproduce on same systems. It's intermittent.

We know. :) Please see the questions in T192054#4129256 - thanks!

In T192054#4129256, @Aklapper wrote:

Does that also happen in other web browsers?
Does that also happen in a fresh, clean browser profile, with all add-ons and extensions disabled?

Sorry, i just don't have bandwidth to run tests, and would rather not install new browsers or profiles on my production PC just for these tests.

It's only happened twice. Have done many other posts and comments with no problem. it's intermittent, So even if I can't reproduce on other browser or profile, that's not definitive of anything.

What will be more practical for me (and maybe more informative) is if I capture behavior on screencapture and/or other capture methods next time it happens.

So I think stalled, can't reproduce, or closed is appropriate case status.

I do not expect a bug in Wikimedia code here but something wrong on the user's system...

Definitely possibly an issue with my own system! Since it happened on 2 machines, same OS and browser, maybe a browser extension is cause.

(Note, it happened on MediaWiki.org, not Wikimedia.org, in case it matters).

I've tried it on Chromium and Firefox, last versions on Ubuntu. I've followed the instructions. I don't have any issue.

It would be great to know if this also happens in a clean profile of your web browser (not using add-ons or extensions which might interfere) and when not using any Wikimedia user scripts or gadgets (by either not being logged in on Wikimedia websites or by always using [[ https://www.mediawiki.org/wiki/Help:Locating_broken_scripts | safemode=1 ]]).

• This video shows more problems with the Flow editor.
• Notice the errors in the text, after clicking "Submit" button.
• i was able to duplicate this with all my browser extensions disabled.
• When tapping down-arrow on keyboard, i noticed the blinking insertion-point disappeared, as if it's gone into a hidden text-buffer beyond the visible text.

As mentioned, i DID test with customizations disabled.
By your logic, every topic that isn't fully tested is "stalled".
Isn't comprehensive testing for the assigned-to folks to handle?
i'm only reporting the bug that happened to me. It's not my responsibility to perform comprehensive tests of this issue.

As mentioned, i DID test with customizations disabled.

T192054#4166354 tasks only mentioned browser extensions disabled.; T192054#4134499 also asked about disabling user scripts and gadgets on Wikimedia sites.

By your logic, every topic that isn't fully tested is "stalled".

See https://www.mediawiki.org/wiki/Bug_management/Bug_report_life_cycle - if nobody can reproduce a problem that only a single user on a single machine ever experiences, that task is indeed "stalled" as nobody can do anything about it. Such a task will very likely end up as "declined".

It's not my responsibility to perform comprehensive tests of this issue.

It is nobody's responsibility, actually.

It looks to me like this is likely to be a bug in VE, or in some sort of gadget or user script interacting with VE.

In the video it doesn't look like ?safemode=1 was used. Is this reproducible with ?safemode=1?

In T192054#4171686, @Catrope wrote:

Is this reproducible with ?safemode=1?

how do i do that?

Sorry, looks like the link had not posted here before: https://www.mediawiki.org/wiki/Help:Locating_broken_scripts explains safemode.

I still see no issues, both using https://www.mediawiki.org/wiki/Project:Support_desk and https://www.mediawiki.org/wiki/Project:Support_desk?safemode=1