Me, @Trizek-WMF and @Catrope had a look at this.
It could be solved with giving the infobox PopupWidget a "before forwards" style:

@JTannerWMF Shall we forward this to VE team?

@Esanders will touch base with @Cntlsn and @Catrope to provide possible solutions and the Growth team will be responsible for implementation.

I don't think we want to apply a different position. This popup is used for all inspectors (all templates, links, citations etc.).

We are able to change the padding within which these inspectors are allowed to render, so we could potentially make the bottom 50px of the screen off limits when this gadget is enabled.

@Catrope I recently added a padding param to OO.ui.Element.scrollIntoView: https://gerrit.wikimedia.org/r/#/c/oojs/ui/+/501663/ . VE uses this for cursor scrolling in https://gerrit.wikimedia.org/r/#/c/VisualEditor/VisualEditor/+/501678/ but it could also be used for Context scrolling.

In this particular case - https://cs.wikipedia.org/wiki/Astolphe_de_Custine - the page is scrollable. The Help panel does not entirely block the access to the template inspector:

@

In T219966#5452051, @Etonkovidova wrote:

In this particular case - https://cs.wikipedia.org/wiki/Astolphe_de_Custine - the page is scrollable.The Help panel does not entirely block the access to the template inspector:

I believe that happens in most cases, it's just less convinient :).

Moving back to Upcoming Work because this is not necessary for Newcomer Tasks v1.0.

This is happening in the Reply tool, too. See @Samat 's screenshots at https://imgur.com/a/w4Q7gPm

In T219966#6221561, @Whatamidoing-WMF wrote:

This is happening in the Reply tool, too. See @Samat 's screenshots at https://imgur.com/a/w4Q7gPm

Good spot, @Whatamidoing-WMF. @Samat are you able to share instructions for how I can experience the same thing you did in the imgur screenshot linked above?

In asking that, I am trying to get a sense for what someone would need to do in this case to reveal/unblock the "Reply" button? Would you/them scrolling the page to reveal the "Reply" button affect the comment you are wanting to respond to? Would it get pushed out of view?

@ppelberg -- I just tried this out on huwiki. You can experience this by turning on the reply tool in beta features, turning on the help panel in your editing preferences, and then going to a User Talk page. The help panel call-to-action always floats above the rest of the page in the bottom right. In the situation I saw, I was able to just scroll a little, and then the reply link I was looking for came out from under the help panel call-to-action. To me, that seems like a normal and expected behavior for the user to do. @Samat and @ppelberg, do you think that letting the user scroll is an intuitive enough behavior here? Or should we be thinking about this differently?

In T219966#6229849, @MMiller_WMF wrote:

In the situation I saw, I was able to just scroll a little, and then the reply link I was looking for came out from under the help panel call-to-action.

+1, @MMiller_WMF. The above describes what I experienced in testing the Reply tool with the help panel enabled on this page: https://w.wiki/UJq.

To me, that seems like a normal and expected behavior for the user to do.

Agreed. @Samat, what do you think? Does scrolling uncover the link and resolve the issue you experienced? Or do you see something different?

We assumed this is not too much of an issue since the user can move the VE components relative to the help icon by scrolling the page. This is the case for desktop, but not for mobile, where both of them are anchored to the viewport. Here's an example of trying to edit an infobox while the user has the help panel enabled (the edit is not related to Growth features in any way):

@Etonkovidova -- could you please look into @Tgr's comment and identify exactly when this does or does not happen? If it happens often, then I do think we'll want to address it. One thing I noticed is that tapping one time on the template opens the bottom sheet with the obscured edit pencil, but double tapping on the template opens the editor (bringing the user to the same destination as the edit pencil). This is not obvious to the user, but it is possible for them to edit the template by double tapping.

I have a couple ideas for addressing this (@RHo):

• We could disappear the CTA button whenever a bottom sheet is opened while editing.
• Maybe we can extend the approach from "add a link" (T269654) to apply to all bottom sheets in the editor, like shown below, where the CTA button is replaced by a small gray question icon in the header of the bottom sheet.

@ppelberg -- FYI that we noticed this issue and we're looking into it.

In T219966#6961782, @MMiller_WMF wrote:

@Etonkovidova -- could you please look into @Tgr's comment and identify exactly when this does or does not happen? If it happens often, then I do think we'll want to address it. One thing I noticed is that tapping one time on the template opens the bottom sheet with the obscured edit pencil, but double tapping on the template opens the editor (bringing the user to the same destination as the edit pencil). This is not obvious to the user, but it is possible for them to edit the template by double tapping.
I have a couple ideas for addressing this (@RHo):

• We could disappear the CTA button whenever a bottom sheet is opened while editing.

On mobile, the expected behaviour should be that the help icon move above the bottom sheet similar to how it shifts position when the device keyboard opens:

• Maybe we can extend the approach from "add a link" (T269654) to apply to all bottom sheets in the editor, like shown below, where the CTA button is replaced by a small gray question icon in the header of the bottom sheet.

I would advise against this since this would involve a lot of messing with the existing edit cards/pop-ups which are unrelated to the Growth features. This is also since one difference with the existing edit cards is that they can be closed via the "x" icon where we have the permanently open Add link suggestion card:

Re-checked all cases described in the task.

(1) the original report: Desktop - editing the template (that was originally reported) - the Help button is smaller now, and the page always allows to scroll (there is enough of footer space on pages on Desktop)

https://cs.wikipedia.org/wiki/Astolphe_de_Custine

(2)
From https://phabricator.wikimedia.org/T219966#6221561. The new reply tool and the Help button overlap each other - https://imgur.com/a/w4Q7gPm.
Checked both Desktop and mobile.
Again due to the smaller size of the Help button (also there might be some adjustments in the Reply tool UI ) it doesn't seem to be the case anymore. I tried extensive reply nesting - the Help button is kept on the far right, not interfering with the Reply functionality.

For the small screen sizes the issue might be present:
a) when Desktop screen size is less than 1230px, the Help button will overlap the "Reply button"

b) When mobile screen size is small, the Help button overlaps the Publish button. But the Publish button is always accessible and functioning as expected.

mobile

(3) The case reported by @Tgr - https://phabricator.wikimedia.org/T219966#6934201 - is a real issue on mobile.
In the VE mode clicking on the template (the info box) will make the Help button overlap the template editor Edit button. It happens on all infobox templates and on some other templates as well.

(4) Section editing on mobile. If the section has enough text for the whole viewport (or more) the Help button will obscure some text and potentially making it more difficult to edit.

(5) VE link inspector on mobile. The Help panel button will be displayed over the link inspector.

I think we should talk about this after releasing "add a link". I'm putting it on a list for later.

@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 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:

@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#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.

Yes but I would suggest checking that the z-index solution is definitely not feasible first, as that would still be the "proper" fix whereby the edit cards are always above the float help button.

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.

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:

• When VE's context item is not shown, help panel needs to appear on top of VE's overlay. Otherwise this occurs:

• When VE's context item is shown, help panel needs to appear below VE's overlay.

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?

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).

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.:

ve.init.target.surface.context.on('resize', function() { console.log('Context is visible?', ve.init.target.surface.context.isVisible()); });

You'd probably want to debounce it -- there can be a few resizes happening at once before it settles, I think.

(With, you know, appropriate hooking into VE via ve.loadModules then addPlugin, and all that.)

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

With latest changes:

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

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