Page MenuHomePhabricator

Help panel stacking issues
Closed, ResolvedPublic

Description

There are several stacking or collision issues causes by the Help panel displaying over other interfaces. This task is a placeholder to collect them all, discuss a common solution if possible and ease the fixing and QA process.

Overlap issues

Unresponsive button issues

Other non filed possible issues

Screenshot 2025-07-17 at 17.26.52.png (794×1,312 px, 142 KB)
Edit summary dialog

z-index surfaces inventory

Interfacez-indexSource
VE paper surface?Haven't found it. Help panel floating button needs at least z-index: 2; to show above
Help panel buttonunset, lays on the docked menu
Help panel overlay (OOUI dialog)4WindowManager, ProcessDialog
Minerva dock menu9999BottomDock.less

Acceptance criteria
TBD

Open questions

  • How should the help panel overlay surface be stacked, below the docked menu? Stretching vertical space only until the docked menu?
  • How should overlays behave in terms of stacking, should they appear over the docked menu buttons or otoh should they reserve space? As an example, the bug report from T291603 states the

Event Timeline

my suggestion would be to account for the space by setting a padding-right equivalent to the floating button + margins, something like this:
...

image.png (840×332 px, 54 KB)

That could work but the challenge is to find a solution that scales for the amount of use cases there may be around this stacking problem. I have found for instance T291603: Help panel: guidance floating button appears over the Notifications mobile where the requirement is the opposite in terms of stacking, the button should not show or stay behind the notifications overlay (which by the way seems now broken again). Also there's the case where several buttons could be docked.

We could try to set a rule by context (is the help panel button relevant in that view?) or by interface priority (eg dock menu buttons always appear on top of everything, which is what currently Minerva is already enforcing, source ). I believe we should try to keep the help panel as reusable as possible in the sense it could be rendered almost anywhere. Whether it's a good idea to show it over overlays in general I'm not sure but if that's the case it seems every overlay in MW should check whether there's a dock menu present when displaying and reserve space for it.

Note: Back when the help panel and suggested edits dialogs were created there wasn't Codex or an standarized z-index stacking scale available as we do now which will help to solve the issue.

Change #1172624 had a related patch set uploaded (by Sergio Gimeno; author: Sergio Gimeno):

[mediawiki/extensions/GrowthExperiments@master] fix(HelpPanel): temporary fix for z-index overlap issues

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

Change #1172624 merged by jenkins-bot:

[mediawiki/extensions/GrowthExperiments@master] fix(HelpPanel): temporary fix for z-index overlap issues

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

Michael assigned this task to Sgs.

All the subtasks have been resolved: Sergio's change fixed the issues!

I think this task can now be closed? Further work due to z-indexes is happening in T400474: z-index/stacking contexts: Tooltips in GrowthExperiments:ImpactModule & WikiEditor disappear under Tools sidebar in Vector 2022.

Also, T285592: Add generally applicable `z-index` stack to MediaWiki skin variables and Codex is relevant context for future archeology.