@ppelberg/ @Esanders: I have recorded all the test results for this on the Reply tool QA workbook:

Completed testing on the following wikis:

@ppelberg: Checked for new regressions for VE on iOS 14. The only issue found was the crashing issue T264376.

Checked the events for both action: "dialog-abort" and action: "dialog-close" on all kinds of nodes. There is now only one event getting logged for each.

In T264133#6506199, @Esanders wrote:

Should be easy to test :)

In T258988#6494231, @Esanders wrote:

The steps in T258988#6342883 will still trigger a full page reload when you go back to the read page, so I suspect it was just chance that this happened when you followed these steps. The fact it only breaks sometimes suggest there could be a race condition though, which would just result in it occurring seemingly randomly.

Do you see any errors in the console when it hangs? Or any failed requests in the network tab?

All other sub-tasks are working on both Beta cluster and Patch Demo, except T263061.

@matmarex/@Esanders: I checked this on Patch Demo, this seems to be not fixed.

So it starts with a crash while adding a map to the page and then it does not recover from that state.

@matmarex: I am not seeing any of the fixes for the sub-tasks on Beta cluster. Let me know when they are ready to be tested :)

Reopening since this still happens sometimes for me.

Yes, I re-tested it few times now and it seems Issue#1 is fixed.

@matmarex: Also, for sequence 6, I am noticing that, sometimes I am getting the error message "Edit Conflict" for the second user and sometimes, they just get posted one after the other just fine. Is there a specific criteria that will trigger this message?

In T252558#6374443, @matmarex wrote:

I've been testing at https://en.wikipedia.beta.wmflabs.org/wiki/Talk:T252558 and I can't reproduce the problem any more. Hopefully that really fixed it and I didn't just get lucky.

In T259855#6413004, @ppelberg wrote:

In T259855#6408875, @Esanders wrote:

1. No (or at least we don't think so)

Understood.

2. The testing instructions are for issue 1 which we were already pretty confident is fixed. Issue 2 was only ever reproduced by hacking to code to introduce some mock server issues. The best we can do is to re-test edit conflict-type situations (although we already did this with the initial release).

Roger that. Then, let's do the following:

• To ensure "Issue 1" is resolved, let's repeat the steps listed in the task description's "Testing instructions" section. This action is reflected in the "Resulting action" section below.
• To ensure "Issue 2" is resolved, let's do two things [i]
  • A) Complete a full regression test of the Reply Tool, which we've already planned to do as part of the re-deployment of T252558
  • B) Once 622176 lands, inspect a sample of Reply Tool diffs to ensure there are no instances of content corruption using the run the script @matmarex wrote and shared in T260393#6384098. This work will happen in this task: T261321.

Resulting action

• @Ryasmeen, in light of what Ed shared in "2." above [i], are you able to follow the steps listed in the task description's "Testing instructions" section to determine whether "Issue 1" (also described in the task description) is indeed fixed? You can re-use the pages you tested on in T259855#6378321 for this testing.

---

i. @Esanders, please comment if anything here looks unexpected/problematic to you.

Realized that the last issue on Korean wiki is probably related to T260294? Can check again once that one is fixed.

Last update:

Sorani Kurdish:

First update on first four target wikis:

Checked on the following pages:

In T252558#6360756, @Esanders wrote:

Thanks, can you link to a diff of this happening?

@ppelberg/@DLynch/@Mayakp.wiki: Checked Issue#1 (Scenario 3a and 3b) on nl wiki using the mobile site on desktop and on iOS safari after wmf.2 deployment today. The events are now firing with editor_interface being included. I have updated the QA template with the updated test artifacts and changed the status to "Passed" for both the scenarios.

Checked the two events on Beta. They seem to be firing as expected.

Scenario B has failed: because there are two reply links appearing, instead of one. One in the middle of the comment another at the end of the comment as if they are treated as two separate comments.

In T252558#6352463, @Esanders wrote:

It's possible but very unlikely to get edit conflicts with this tool. The two requests would need to arrive at the server probably within a second of each other. That said when it does happen, the behaviour you describe in (2) sounds correct as these are the rules for same-user edit conflicts.

I couldn't reproduce the issue you described in (1). Did both users see the comment they just posted highlighted? The first users to complete will see just their comment, while the second users will see two new comments when the page updates.

I have not checked using two devices yet. Let me know if you want me to do that as well. I can do Windows-Mac, Mac-Mac combinations.

I shouldn't think this would make a difference.

Checked all the sequences. Sequence 1 to Sequence 5 seem to be working as expected.

In T258988#6345900, @JTannerWMF wrote:

Hey @Ryasmeen , the engineers are unable to reproduce this, can you show @ppelberg what you're seeing during your 1:1.

This is now fixed and so are all the other issues I was running into in T258988.

In T252925#6334989, @Ryasmeen wrote:

I have re-checked the scenario 1a, 1b, 2a and 2b on article pages using trackdebug=1. They seem to be working correctly now. Added the test artifacts on the QC template. @Mayakp.wiki/@DLynch might need to review those.

In T258988#6343031, @ppelberg wrote:

In T258988#6342883, @Ryasmeen wrote:

1. This is happening on Chrome on Mac. Tried it on Safari, cannot reproduce it there. Also not on Windows.
2. This seems to be get fixed when I do hard refresh on the page but then comes back again when I switch to the discussion page. The steps are as follows:
   • Open VE on this page: https://en.wikipedia.beta.wmflabs.org/wiki/User:RYasmeen_(WMF)/sandbox
   • Now click on Discussion page of this page from the top bar.
   • Go back again to the first page by clicking on "User page" on the top bar.
   • Now click on Edit.

At this point, the URL changes to https://en.wikipedia.beta.wmflabs.org/wiki/User:RYasmeen_(WMF)/sandbox?veaction=edit, but VE does not open.

Hmm, I'm having a hard time reproducing the above.

When I follow the steps above I am able to open VE [I think]: https://youtu.be/NsKfX76pZbU

Environment:

• Chrome 84.0.4147.89
• macOS 10.15.4

I am wondering if this is part of a bigger problem on Beta cluster. I am also being unable to switch tabs on Preferences page on Beta cluster at this point. There is an eternal loading bar animation appearing for the field "Prohibit these users from emailing me:" on my User profile page. Again this is happening only when I am using Chrome.