In T213120#5549335, @ppelberg wrote:

In T213120#5095449, @Ryasmeen wrote:

ok, this time it's real. Still seeing this on bn.wiki. Here is the video capture:

ScreenRecording_04-08-2019 13-24-59.mp41 MBDownload

I seem to be encountering the same issue Rummana encountered above:
Actual behavior

1. Edit the body of a section
2. Publish changes

⚠️ 3. View is scrolled to the top of the article in read mode
Expected behavior

1. Edit the body of a section
2. Publish changes

✅ 3. View is scrolled to the top of the section I was just editing
Configuration
Browser: Safari
Device: iPhone Xs
OS: iOS 13.1.2
Video
https://youtu.be/fikbhfZjmJE

@matmarex: You're right. It was happening couple hours ago, but not anymore. Guess it was not updated at that point.

I am still getting the following error with cutting references.
Check the screenshot for the error:

In T232790#5545449, @ppelberg wrote:

In T232790#5544653, @DLynch wrote:

Everything Rummana saw looks correct, it's just a confusion about what the event name is. For the VisualEditorFeatureUse events it's two-part, there's a feature and action component, with the name being written here as [feature].[action].
e.g. this console log shows the mwSave.checkbox-wpWatchthis event:

Got it. Thank you for demonstrating this and for updating the task description accordingly, David.

In T232790#5544672, @DLynch wrote:

That said, the "Yes, but it's getting fired twice" shouldn't be firing twice. But I can't reproduce that myself, so I might need more information.

Never mind, worked it out, patch incoming.

Excellent.

Next steps...

• @Ryasmeen, all that's left now is to test the two actions in the table below that you correctly identified as being fired twice in your initial testing:

Action	Event that should fire	Did event fire? Y/N	Notes
tap "This is a minor edit" checkbox in the "Save your changes" screen	VisualEditorFeatureUse: mwSave.checkbox-wpMinoredit	Yes, but it's getting fired twice
tap the "Watch this page" checkbox in the "Save your changes" screen	VisualEditorFeatureUse: mwSave.checkbox-wpWatchthis	Yes, but it's getting fired twice

In T233127#5522908, @Waddie96 wrote:

In T233127#5520602, @Ryasmeen wrote:

In T233127#5509477, @kaldari wrote:

@Ryasmeen - Can you reproduce this bug? (Note that it's specifically happening when there is an edit conflict and the two-column edit conflict beta feature is active.)

Yes @kaldari, I was just able to reproduce this but only once:

Did you encounter it secondary to an edit conflict or independent of that?

@ppelberg: I went ahead and gave it a round of testing. I have noted my observations. The only thing is, for all events the word save. is not appended. And the last two events are firing twice.

In T233127#5509477, @kaldari wrote:

@Ryasmeen - Can you reproduce this bug? (Note that it's specifically happening when there is an edit conflict and the two-column edit conflict beta feature is active.)

In T217769#5512172, @matmarex wrote:

@Ryasmeen If that's only when the keyboard is open, then that is unavoidable on iOS, IIRC we need it for the toolbar hacks (T218414). When the keyboard is closed, the issue should be fixed.

Still reproduce on Beta when I tap at the end of the article, was testing on the same article.

@ppelberg: This is regression pre-wmf.24, so it's on Beta.

@matmarex: I only checked two of the cases here. Can we skip QA on this one, it seems like a low priority thing with lots of technical details.

In T215604#5035235, @matmarex wrote:

I can't reproduce (testing on https://en.m.wikipedia.org/wiki/The_Fighting_Temeraire).
Video: https://drive.google.com/file/d/1S496riNZy-oOgrB_Wq789MROSGMahw6M/view (too large to upload to Phabricator). I can view and use the last entry in the dialog while the keyboard is open.
It is a bit fiddly due to T212159: Scrolling a ProcessDialog scrolls the page behind on iOS Safari (if Safari decides to scroll the page behind the dialog, any further swipes will keep scrolling it instead of the dialog, but if you wait until the scrollbar fades out, then you can start scrolling the dialog again – you can see this happen in the video at 15-17 seconds). But with a bit of patience, everything in the dialog is reachable, with keyboard open or not.

@Esanders: By "Scroll-past-infobox code" do you mean the dragging the selection over the infobox was not working. Can you check the screen capture and confirm if this looks fixed?

In T232172#5479540, @JTannerWMF wrote:

In Triage we determined we will move forward with what @Esanders suggested in the last line

hmm...okay, working now. Thanks though @matmarex for quickly checking! :)

This is still happening.

I can still reproduce this issue on Beta. Showed it to @ppelberg today, so reopening it.