I have some notes on this at https://www.mediawiki.org/w/index.php?title=User:Whatamidoing_(WMF)/Sandbox2&oldid=5090122 in case anyone wants to play around with it.

Change 605438 abandoned by Bartosz Dziewoński:

[mediawiki/core@master] [editor] Editor font-size inherits the skin's font-size, 90% for monospace.

Reason:

This would be a disruptive change and we're not going to accept these patches. Sorry.

https://gerrit.wikimedia.org/r/605438

I was about to report the same issue. The automatic edit conflict resolution is quite annoying indeed. This needs to be worked on.

I also said several times the same that someone else has also said in the meanwhile. The automatic edit conflict resolution is one of the most annoying features of the reply tool. So I think

• Do it. Make it opt-in initially if you’re not confident enough, but eventually turn it on for everyone. Opt-out is not needed, everyone should know that there’s a new comment that potentially effects what they want to say.
• Do it pre-submit. This is about letting people know there’s something new that potentially effects what they want to say; it makes no sense after the comment has been published.
• Warning about the whole page can be annoying, so limit it to sections. If it’s not possible or takes long to implement, falling back to MediaWiki’s edit conflict detection (i.e. warning about cases where the full-page editing experience would show an edit conflict) covers most of the cases, namely when two people reply to the very same comment.

I'm using this tool for a while, and I find very annoying noticing edit conflicts just after when the edit has been published.

All looks good in betalabs - moving to Test in Production.

Change 710120 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] Help Panel: Hide CTA when VE's context item is shown on mobile

https://gerrit.wikimedia.org/r/710120

With latest changes:

Change 710120 had a related patch set uploaded (by MewOphaswongse; author: MewOphaswongse):

[mediawiki/extensions/GrowthExperiments@master] Help Panel: Hide CTA when VE's context item is shown on mobile

https://gerrit.wikimedia.org/r/710120

Easiest way is probably to watch for the resize event being emitted by VE's context, then check isVisible() on the context to see whether it's actually shown. E.g.:

In T219966#7244267, @mewoph wrote:

Both removing the button & changing the z-index would require us to know when the context item is shown and dismissed. @Esanders — is there an event in VE that we can listen for to know when the context item's visibility changes?

cc @DLynch @matmarex (Ed is out on leave).

I looked into this a bit and it looks like the CSS-only solution (changing the z-index of the help panel button) isn't possible. This is because the help panel's z-index needs differ based on what's happening in VE, namely:

The next step for this task is to scope it, so that we know when it's appropriate to work on. Therefore, I'm putting it in Ready for Development for scoping.

In T219966#7218635, @MMiller_WMF wrote:

@RHo -- okay, so just to make sure, the proposed solution is still to simply remove the button when an edit card is displayed? Hopefully that will be simple to implement.

@RHo -- okay, so just to make sure, the proposed solution is still to simply remove the button when an edit card is displayed? Hopefully that will be simple to implement.

In T219966#7215068, @RHo wrote:

For desktop […] the issue is mostly mitigated by the reduced size of help icon-only button

…unless one uses Chinese (or Korean or Japanese) user interface:

@MMiller_WMF - this is another item that should ideally be fixed sooner than later as it is a problem particularly for all VE edit cards on mobile.

In T251633#6129747, @cscott wrote:

My note on this is that extension parsing is in theory not one of the "evil" parts of wikitext parsing. After the open tag is seen, the close tag is found using a fairly braindead regexp, more-or-less deliberately. ("You can include any content in extension content except </closetag....".) The only tricky part might be attribute parsing inside the open tag, but IIRC the sanitizer does this with a regexp so you should be able to do that as well. So, yes, it's a slippery slope, but at least the slope isn't *too* steep in this general area.