I checked all the events on both Mobile and Desktop. Here are few of my observations:

In T338171#9197799, @ppelberg wrote:

In T338171#9197490, @matmarex wrote:

I just saw the Phab notification today saying that you closed it, and I didn't remember working on it. I see the old copy e.g. at https://de.wikipedia.beta.wmflabs.org/w/index.php?title=Test&action=edit&uselang=en.

Understood, ok. Thank you for confirming, Bartosz.

In T338171#9197512, @Ryasmeen wrote:

That is correct. I checked all of them on https://de.wikipedia.beta.wmflabs.org/wiki/. And I am still seeing the new copies.

@Ryasmeen, hmm. The screenshots you shared in T338171#9197512 do not seem to reflect the IP masking enabled (desired) copy specified in the task description's === Interface messages section.

This leads me to think the new copy has, in fact, not been implemented, as Bartosz noted.

Resulting actions:

1. Moving this to "Ready to be worked on"
2. When this gets back to Editing QA, can you please reference the ✅ IP masking enabled (desired copy) column in the task description

Client-side logging is being emitted as expected on Desktop for logged in users with VisualEditorFeatureUse as feature: notices, action: show. I will test the mobile part once this task is resolved T312587.

That is correct. I checked all of them on https://de.wikipedia.beta.wmflabs.org/wiki/. And I am still seeing the new copies.

In T326500#8545690, @ppelberg wrote:

In T326500#8532536, @DLynch wrote:

@ppelberg We didn't do anything specifically about this, rather enter behaves consistently here with how it does in all HTML forms. (I.e. in multiline fields it adds a newline, otherwise it submits the form.) We can change that, but it's worth noting that it does depart from the generally expected behavior of the entire (browser) platform.

! In T326500#8532539, @DLynch wrote:

The explicit overrides we've done to standard behavior is to not submit the form if it doesn't pass validation (though technically you can also do that within HTML attributes; we're just doing it in JavaScript instead), and adding the meta-enter behavior to submit the form from within the multiline field.

This context is helpful – thank you for walking me through it, @DLynch. I'm curious to hear what Nico thinks about this...

@nayoub: a question for you about keyboard shortcuts and the New Topic Tool...

Below is a current mapping of the keyboard shortcuts people can use to publish a new topic using the New Topic Tool on desktop. Can you share what – if any – risks you can see by modifying the behavior to what's shown in the proposed section?

Cursor focus	Subject field empty	Description field empty	CURRENT shortcut required to publish new topic	PROPOSED shortcut required to publish new topic
Subject field	No	Yes	N/A; not able to publish new topic using shortcut when Description field is empty	---
Subject field	No	No	⏎	⌘ + ⏎
Description field	Yes	No	⌘ + ⏎	---
Description field	No	Yes	N/A; not able to publish new topic using shortcut when`Description` field is empty	---

A separate task has been created for this: T346405. We can close this one! :)

On mobile, when Edit Check is getting triggered and I tap "Yes" to proceed, it takes me to the "Add a Citation" dialog. But when I tap on any of the options on that dialog to add a reference, it takes me straight to the save dialog, without giving an opportunity to add the citation. It even shows the toast "Thank you for adding a citation!".

The events here are recorded server-side, so I am not seeing them being triggered from my browser.
I looked at two places: https://schema.wikimedia.org/repositories/secondary/jsonschema/analytics/legacy/templatedataeditor/latest.yaml and https://meta.wikimedia.org/wiki/Schema:TemplateDataEditor. I do not see user_is_temp there.

@Esanders: Yes, I can reproduce on that version too. Here is the diff: https://patchdemo.wmflabs.org/wikis/d5223a3ee5/w/index.php?title=Douglas_Adams&diff=152&oldid=138.

In T340086#9097624, @ppelberg wrote:

In T340086#9097616, @Ryasmeen wrote:

@ppelberg: Edit check is still being triggered when an edit involves content being removed that is adjacent to new content being added.

It also gets triggered when an edit involves content being added that is adjacent to new content being added. But not sure, if this is also something we are thinking of removing from our initial heuristic.

Great spots, @Ryasmeen.

Per adjustment "1." in the task description, Edit Check being activated in edits when content is removed in places adjacent to new content being added is unexpected.

I'm going to assign this back over to @Esanders to have a look.

Rummana, in the meantime, can you please share a link to a diff that demonstrates the unexpected behavior described above?

@ppelberg: Edit check is still being triggered when an edit involves content being removed that is adjacent to new content being added.

I just checked this on iOS 16.0.3, when I leave the page with an unfinished comment and reload the tab, all the other sections are opening except the one where the previous comment was retrieved. Here is a screen capture of that:

This seems to be not working for me on Firefox.

Yeah, I don't see this issue happening anymore for some reason. Closing it as invalid.

This is still happening. Pressing backspace/delete when the cursor is in the empty paragraph selects the previous table, doesn't delete it.

It seems the edit intro message is appearing only when you load the page following the link that has the 'editintro' url parameter. But, it's still not showing the edit notice when you click on the 'Edit' button directly on the same page which I think what the new patch was for?

A few observations:

We are done testing Discussion Tools from our end. We didn't find anything broken for DT that's relevant to this change.