fix: dropdown menu rendering above headers

[LeonardYam]

Problem

Currently, dropdown menus are being rendered above sticky headers when scrolling. This behaviour can be seen during form creation and in public forms.

This was caused by FloatingPortal in SelectMenu.tsx which portals the dropdown menu into the document body, making it render above everything else in the app.

Closes #6026

Solution

Remove FloatingPortal, then assign the dropdown z-index value from Chakra UI to the menu, ensuring it still renders above other elements appropriately.

Side-notes:

• Suppression of ref error is removed since a portal is no longer used.
• I believe the current public form header uses the wrong z-index value, currently it is 1000 which corresponds to dropdown in Chakra UI instead of 1100 for sticky.

Breaking Changes

• No - this PR is backwards compatible

Before & After Screenshots

BEFORE:

AFTER:

Tests

• Create a form with a dropdown field, ensure dropdown field does not render above sticky headers

[foochifa]

Hi @LeonardYam thanks for the contribution! Do give us some time to get on this PR!

In the meantime could you rebase to develop and resolve the existing conflict? Thanks!

[LeonardYam]

Hi @foochifa, I've just rebased the branch! I've tested the changes on my local build.

Screen.Recording.2023-07-06.at.12.40.21.AM.mov

[foochifa]

Sorry @LeonardYam didn't see the convo in the issue #6026! Honestly, would prefer if we kept the floating-ui's portal cause:

1. easily handles clipping issues
2. positioning of the dropdown depending on reference component and viewport

Was perhaps looking into exploring using floating-ui's hide middleware

But welcomed if you have other suggestions!

If you need more help feel free to reach out too!

[LeonardYam]

Hi @foochifa, so sorry for the late reply! From what I've read, portals mainly have two use cases:

1. Rendering an element above everything else regardless of stacking context (i.e. modals)
2. Resolving clipping issues caused by parent containers which has an overflow:hidden style

If I'm not wrong, the dropdown menu does not fall into these use cases, which was why I opted to remove the portal. On the other hand, we could also keep the portal for defensive programming etc.

I'll have to explore on how we could keep the portal (either through portalling into a suitable element or using the hide middleware), let me know what approach would be preferred!

positioning of the dropdown depending on reference component and viewport

Sorry I'm quite new to webdev so I don't quite understand this point 😅.

[foochifa]

Heya @LeonardYam

No worries, I realised most of the concern is still taken care of by floating-ui thru style={floatingStyles}, which helps to position the popover correctly.

Was partially worried about potential clipping of the popover (either by length of options or by number of options) without portal-ing but seems like virtualisation and our styles in DropdownItem managed to handle any such issues.

Am just running the CI/CD tests now, thanks for the contribution!

[foochifa]

Sorry! Gimme a lil time @LeonardYam, will probably have to pick your commits into a new branch within our repo to run the chromatic tests, will create a new PR to ensure the tests pasts first 🙏

[LeonardYam]

Hi @foochifa, no worries! Thanks for the review! Let me know if there are any issues with the tests!

[foochifa]

@LeonardYam Sorry for taking some time to get back to you, after discussing with UX, actually both the interaction in the screenshots are undesired.

For the after screenshot, it's because there are elements that are interact-able but hidden from view. This also applies to the before screenshot, when scrolled out of view.
This breaks UX as we shouldn't be able to interact with things we can't see, in this case, we could scroll out of view and 'up', 'down', 'enter' to select and input a result, without actually seeing the result get populated in the form field.

To fix the case above, one of the ways is to use floating-ui's hide middleware, another could be to check whether the ref component (combobox itself) is in the view maybe using IntersectionObserver. Would you like to continue working on this issue, it will require more work but might be fun hahaha let me know!

And sorry for the last minute changes to the intended behaviour in the issue.

[LeonardYam]

Hi @foochifa, no worries! Good point about the UX, i would like to continue working on this!

[LeonardYam]

Hi @foochifa, sorry for the late update! From my initial testing, the hide middleware fix works as intended for the form creation page! However, this does not work for public forms. I think that the usage of the sliding header interferes with the clipping calculations.

I will investigate further and get back to you on this!

[LeonardYam]

Hi @foochifa, unfortunately upon further investigation, I don't think it is possible for the hide middleware to fix the bug in the public form. As a workaround, I made a custom middleware that detects when the slide header covers the combobox (bottom-left corner specifically).

Let me know if this works!

Behaviour:

recording1.mp4

[foochifa]

Nice thanks @LeonardYam will take a look asap!