+1 on the menu being cut off/behind the header. this seems like an z-index issue. @CCiufo-WMF should we file a task on the design system board too?

regarding the display position of the menu, that's the built-in behavior of the codex lookup/menu component. based on the number of results, and the available space, the menu will be displayed upward or downward (attached gif)

This has also been the case for a long time when searching for a function in a composition. Most often the one that appears just off the screen is the exact one you want. To test this, try searching for the "if" function in a composition.

@DVrandecic @99of9 are you using Firefox? It is working fine for me in latest Chrome on macOS.

This could be connected to a known issue: T353072: Menu: Floating menu flips too early in Firefox, although an issue with the z-index wasn't identified previously.

@CCiufo-WMF I'm on Chrome on a Windows laptop. My browser is full screen, so the content is not in single-column view like yours.

Steps to reproduce:

• Open your browser full screen on a laptop/desktop.
• Go here: https://www.wikifunctions.org/w/index.php?title=Special:CreateObject&uselang=en&zid=Z14&Z14K1=Z19232
• Open the "select function" dropdown

*In "function" type "if"

In T377337#10240380, @99of9 wrote:

@CCiufo-WMF I'm on Chrome on a Windows laptop. My browser is full screen, so the content is not in single-column view like yours.

Steps to reproduce:

• Open your browser full screen on a laptop/desktop.
• Go here: https://www.wikifunctions.org/w/index.php?title=Special:CreateObject&uselang=en&zid=Z14&Z14K1=Z19232
• Open the "select function" dropdown

*In "function" type "if"

Got it, yes I'm able to reproduce this one. Still can't repro the example in the task description though. Either way, we can look into this issue.

In T377337#10240459, @CCiufo-WMF wrote:

Got it, yes I'm able to reproduce this one. Still can't repro the example in the task description though. Either way, we can look into this issue.

@CCiufo-WMF i was able to reproduce the issue with the example in the task description on a fresh google chrome install, version 130.0.6723.59. attaching a gif, i hope this helps!

interesting enough, on another chromium-based browser, i'm able to reproduce the issue only when the viewport height is set to less than 520px.

In T377337#10241079, @AAlhazwani-WMF wrote:

In T377337#10240459, @CCiufo-WMF wrote:

Got it, yes I'm able to reproduce this one. Still can't repro the example in the task description though. Either way, we can look into this issue.

@CCiufo-WMF i was able to reproduce the issue with the example in the task description on a fresh google chrome install, version 130.0.6723.59. attaching a gif, i hope this helps!

interesting enough, on another chromium-based browser, i'm able to reproduce the issue only when the viewport height is set to less than 520px.

That was helpful, thanks! I am able to reproduce it now in certain scenarios, depending on the viewport size and resolution.

Assigning 1 pt so that an engineer from DST can confirm the issue and make a recommendation for a fix (we may not need to update anything in Codex).

IMO this is a combination of 2 issues:

1. As Chris mentioned, in FF (and potentially other browsers apparently) the menu flips too early. When I open this menu in FF it opens up when it should clearly open down. We should investigate T353072 and see if we can force the menu to first try opening down and clipping reliably (it is designed to work this way but doesn't).
2. Even when the dialog should open up, it's displaying under the page header. Dialogs within the content pane opened in place will never overlap the outer chrome of the page for Reasons - @egardner can you remind me/us of this issue and how to resolve it via teleporting the dialog? That will at least resolve the visible bug while DST tries to fix the flipping issue.

This is not a Codex issue. It's a z-index issue that originates in Vector.
This is a Codex issue that is being exacerbated by some of the z-index styles in Vector and MW.

Vector styles have been structured in such a way to make it impossible for anything that descends from the .vector-body element (which is given an explicit z-index of 0) to stack on top of the .vector-header.mw-header element (which has a z-index of 3). This is because no child element can have a stacking level higher than that of its parent/ancestor, regardless of what z-index that element has in its own styles.

The Codex menu itself has a z-index value of 50 (per the @z-index-dropdown token we use), but this is overridden by the 0 value on .vector-body.

If the z-index: 0 rule on .vector-body is removed, then things work as one would expect (the menu appears above the Vector header while it is open).

Floating UI (the library Codex uses for menu positioning) acknowledges that z-index rules may cause issues. Per the FloatingUI docs:

Floating UI does not have opinions about how your elements stack on the z-axis. This means your element may be occluded beneath another positioned element if it has a higher z-index.

Due to the complexity of this, it is up to you to handle the z indices of various floating elements in your application.

There may be some kind of workaround we can do, but my suggestion would be to reconsider that rule in Vector. Applying z-index: 0 on to .vector-body feels like overkill and it ensures that nothing from the page content can ever overlay anything in the page header. @Jdlrobson what do you think?

I believe the rule .mw-header { z-index: 3; } was introduced back when Vector 2022 looked identical to Vector and used absolute positioning for its header to make sure search results were not clipped by elements in the UI. I think that is the issue here, not the z-index: 0?

That aside are we sure we want UI elements overlapping the header? While it is not a problem here given the search results hide on a loss of focus it could be a problem if UI elements do not.

(bd8339865990edcc3c80ceb3370bba59c10e19f4). It is possible it is not needed now but I haven't checked.

In T377337#10291314, @Jdlrobson wrote:

I believe the rule .mw-header { z-index: 3; } was introduced back when Vector 2022 looked identical to Vector and used absolute positioning for its header to make sure search results were not clipped by elements in the UI. I think that is the issue here, not the z-index: 0?

It's fine for the header to have a z-index of 3 since it's meant to overlap normal page content when the user scrolls. This behavior would still work as expected if the .vector-body element had no z-index specified in its own styles.

The problem is that when a large chunk of the page sets z-index to 0, nothing inside that container can ever escape from that level of the stacking context. When z-index 0 is applied to .vector-body (or .mw-body-content, which also does this), it means that lots of menus, dropdowns, popups, and other page elements won't be able to reach their intended stacking level.

Aside from the z-index: 0 issue, it does look like the Codex menu is flipping too early in this situation. Menus are supposed to flip when there is not enough space available below them, but in this example it seems to be happening sooner than it should. So maybe it's more accurate to say that this is a Codex issue that is being exacerbated by some of the z-index styles in Vector and MW.

One potential workaround that Abstract Wiki could try now would be to set a visibleItemLimit (with a value of 5 or 6) on that Lookup component. Maybe a smaller menu would do less of this unexpected flipping.

If that doesn't address the issue, then we might need to post a patch that modifies some of our floating menu behavior and have one of the Abstract Wiki developers test it out in their local dev environment. We wouldn't want to merge anything unless we could confirm that the correct behavior was being produced in this situation.

@DVrandecic is there an AW engineer who is available to help out a bit on this task? Shouldn't require too much time from their end, but this will be much easier if someone that already has a working dev environment for Wikifunctions can test things locally and report back.

@egardner I can help with that.

Re: z-indexes, IMO it would make sense to remove the z-indexes on the page layout sections to allow the more specific z-indexes on individual components to take effect. This is how the scale is meant to work, and the z-indexes on .mw-header and .mw-page-container are interfering with that. In theory, removing these z-indexes shouldn't negatively affect the TypeaheadSearch menu, since it (along with all Codex menus) has a z-index of 50 and, as Jon mentioned, most menus are only open when focusing on the triggering element so only one should be open at a time.

However, if any other features/gadgets/whatever use z-indexes outside of our scale, there could be an element that covers the TypeaheadSearch menu. If this is an issue, we could put a very high z-index on just the Vector TypeaheadSearch menu to ensure that it overlaps anything. Again, since the menu closes as soon as you move focus outside of the search box, I don't think it would be an issue (e.g. if a dialog launched).

Some other options:

1. Do what OOUI does and teleport menus to a target at the bottom of the body element
2. If we decide we don't want anything overlapping the header: update Codex's FloatingUI usage to detect if there's a .mw-header element and account for it when calculating the height of a menu that's opening upward
3. Don't flip menus in MW, or enable dev users to configure feature-specific menu components not to flip

Adding configuration in Codex components to turn off flipping at the feature level would be the quickest and least risky way to resolve this particular bug.

In T377337#10291860, @gengh wrote:

@egardner I can help with that.

Thanks! @gengh my first suggested workaround is very simple – let's try applying a visibleItemLimit to the menu inside this particular Lookup component.

The Lookup component exposes a menu-config prop that gets passed down to the child Menu component. So in order to set this property you'd do something like this:

<cdx-lookup
    :menu-config="{ visibleItemLimit: 5 }"
>

This demo is a more complete example (the menuConfig object is set up near the bottom of the file).

Assuming that you can reproduce the problem in your local environment, can you add this config option and see if it makes any noticeable difference? I'm hoping that a menu of limited height won't flip as much, and it's a good UX anyway (we don't necessarily want to present a huge list of items to the user all at once, it can be overwhelming). You can adjust the value to see if you notice anything at different limit sizes, but I'd suggest something around 5 or 6 to start.

If you could test this out and report back (posting screenshots or other info if necessary) that would be helpful. If this simple workaround does not work I have other ideas, but let's start with the lowest-effort approach first.

I suspect you also will want to test this with the sticky header (e.g. with a page where the lexeme selector appears further down the page):

In T377337#10293756, @Jdlrobson wrote:

I suspect you also will want to test this with the sticky header (e.g. with a page where the lexeme selector appears further down the page):

This is a case where I think you probably do want the menu to be able to overlap the sticky header when it is open (which is not possible when the .vector-body and .mw-body-content have z-index: 0 set).

But I'm also hoping that limiting this menu to only show 5 or 6 items at once (user must scroll in the menu to see more) will help prevent these collisions from happening as often.

Setting the visibleItemLimit does help in avoiding the problem.

When using a lookup that's set on the superior side of the page:

When using a lookup that's placed more towards the bottom, the menu options display above, but they fit the space properly:

I also agree that the result feels less overwhelming and still allows contributors to navigate through the options.

@AAlhazwani-WMF what do you think?

Additionally, although the use cases are not so common, this issue can also be replicated in our other instance of Codex Lookup, the ZObject selector.
For example, while using the language selector after expanding text to find the language of in the language of monolingual text/Z14404 function:

I would suggest making the same change to limit visible items to 5 in both our selectors (the Wikidata entity one referred to in this conversation, and also the ZObject selector).
This would be the outcome for the language example above:

Change #1087868 had a related patch set uploaded (by Genoveva Galarza; author: Genoveva Galarza):

[mediawiki/extensions/WikiLambda@master] Limit lookup visibleItemList to 5 in ZObject and Wikidata entity selectors

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

In T377337#10295322, @gengh wrote:

Setting the visibleItemLimit does help in avoiding the problem.

When using a lookup that's set on the superior side of the page:

When using a lookup that's placed more towards the bottom, the menu options display above, but they fit the space properly:

I also agree that the result feels less overwhelming and still allows contributors to navigate through the options.

@AAlhazwani-WMF what do you think?

agreed! it might happen that it's not immediately clear that the menu is scrollable, mostly because it exactly crops 5 menu items, but for that we already have T368421: Menu: Evaluate improvements to scrolling UX

In T377337#10295348, @gengh wrote:

Additionally, although the use cases are not so common, this issue can also be replicated in our other instance of Codex Lookup, the ZObject selector.
For example, while using the language selector after expanding text to find the language of in the language of monolingual text/Z14404 function:

I would suggest making the same change to limit visible items to 5 in both our selectors (the Wikidata entity one referred to in this conversation, and also the ZObject selector).
This would be the outcome for the language example above:

@gengh +1!

Change #1087868 merged by jenkins-bot:

[mediawiki/extensions/WikiLambda@master] Limit lookup visibleItemList to 5 in ZObject and Wikidata entity selectors

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

Thanks @gengh for that patch. Looks like this addresses the immediate issue.

I think that it is still worth exploring changes to how we limit the ability of items in page content to set their own z-indexes, but that can be handled separately.