Actually, the same error appears when you select an image while adding a gallery.

In T208826#5100939, @Esanders wrote:

Yes (see T219829) and yes :)

In T208826#5099501, @Ryasmeen wrote:

But we seemed to fixed few more things as part of this, which is the selection on the editing surface will be grayed out if the heading is also selected, but it would be allowed to select both none the less? Is that correct?

Yes, those are reflected in the child tasks T219813 and T219829.

However I noticed something that if you select heading first. and then try to select a text from the editing surface, it deselects the heading. That's also expected right?

Yes.

This bug is now on test.wiki, changed the title to reflect that.

@Esanders: Followed the steps of the original issue mentioned on the task, which seems fixed. But we seemed to fixed few more things as part of this, which is the selection on the editing surface will be grayed out if the heading is also selected, but it would be allowed to select both none the less? Is that correct?

In T218635#5068141, @matmarex wrote:

@Ryasmeen I think the issue we're seeing in that video is identical to T218650: In mobile VE, using the "Format" menu causes the page to scroll up by ~half the screen every time (iOS only?). Maybe we're also seeing T219200: [Regression wmf.23] Viewport sometimes jumps to the top abruptly on mobile VE. I'm pretty sure that this bug is actually fixed, and those are separate issues, but let's keep it open until we resolve them as well and can verify this.

In T219200#5096998, @matmarex wrote:

In T219200#5079165, @Ryasmeen wrote:

When can we have the fix for it on Beta cluster?

It's live on Beta now.

@Esanders: I just checked this on Mediawiki, seems to be happening there too when the text is closer to the toolbar. Here is the screenshot:

The option to add musical notation itself is missing from the menu.

I see, alright I am closing this then.

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

In T219950#5087042, @ppelberg wrote:

@Ryasmeen for the wikis you found Section Editing not to be present on, was your userinfo":{"id": odd or even?

---

userinfo":{"id": can be found for each wiki by modifying the wiki "prefix" (the first two letters in the URL): https://en.wikipedia.org/w/api.php?action=query&format=json&meta=userinfo

---

Also: I updated the task's description to include the proper link to zh-classical

Here is the test result for me:
Section editing is present on: ja wiki, it wiki, pl wiki, hu wiki, da wiki, sr wiki, sv.wiki, ro wiki.
Section editing is not present on: no wiki. zh wiki.

In T213120#5086856, @DLynch wrote:

@Ryasmeen -- honestly, the weird part there is that it worked on en.wiki. We have a train stall at the moment, so en.wiki should still be on 1.33.0-wmf.23 which doesn't have the latest patch.

This is really weird, I tested this on Beta cluster, test.wiki, en.wiki and it worked in all three environments, except it's still not working for bn.wiki. I have no idea what it is that I am doing different for this wiki :(

@Esanders: So I checked this today on @Catrope's Android 9, Moto X4 device. It seems the context menu is still obscuring the VE toolbar. Am I looking at the right thing here?

When can we have the fix for it on Beta cluster?

@matmarex: so this scrolling issue seems fixed. However, T218635 still is not.

Fixed now, Thanks BD! :)

Yes! Neil verified that based on my account ID, that's expected.

So this is the error that appears in the console when it's failing: jQuery.Deferred exception: Cannot read property 'defaultthumbsize' of undefined TypeError: Cannot read property 'defaultthumbsize' of undefined

In T218429#5068520, @matmarex wrote:

@Ryasmeen Argh, that seems to be a general problem with the loading overlay (not specific to iOS Safari, like this bug). I copied your comment to that task: T210630#5068517. It's a valid issue but I'm not sure if it's worth working on (see my comment there).

I don't think it's related to this task; if that's the only issue, then I think we can resolve this.

In T219200#5068425, @matmarex wrote:

@Ryasmeen I encountered a similar problem when testing the link dialog (for T218635). I am not sure if this is actually the same problem as yours, but I hope it is.

I deployed the patch above to the prototype site (https://visualeditor-prototype.wmflabs.org/wiki/Pride_and_Prejudice). Can you test if it fixes this problem for you?

@JTannerWMF: Now it can go to Product Owner Review :) It just landed on en.wiki earlier today with wmf.23 deployment. And I checked all the relevant tasks associated with this, and added comment where appropriate.
Marking it done from QA side.

@matmarex: Thoughts on this?

@matmarex: Alrighty! So I checked this today on en.wiki, looks okay to me. I just have one question:

Yeah I am okay with that @JTannerWMF, specially since it's not blocking any workflow.

@matmarex: I see that you had the page loaded from before on the other tab, did you refresh and loaded it fresh?

@matmarex: Could you try this one more time following these steps:

In T219200#5058450, @JTannerWMF wrote:

We will see how this behaves post production

Is it possible that @Neil_P._Quinn_WMF is experiencing this now: T219200, which is happening on iOS Safari too and a regression?

Checked on test.wiki doesn't seem that bad on this environment.

and calling it a regression since it's not happening on en.wiki.

This is now happening on test.wiki as well, it is very distracting and we should definitely look into it. We fixed a similar bug for source mode last week, but this time it's happening on VE.

@matmarex: This needs to be tested on a wiki with section editing disabled, so I will wait until it's on en.wiki?

@matmarex: This seems to be still happening on Beta cluster? Maybe it does no go the top most area of the article but towards the top still. Video: