ComboBox dropdown not visible

[SStalciuss]

Describe the bug (actual behavior)

ComboBox menu is not visible if it is outside of parent and one of the parents has overflow property set, even with boundary set to window/document.

Expected behavior

ComboBox menu is visible even if it is outside of a parent if boundary is set to window/document.

Reproduction

https://stackblitz.com/edit/react-ts-pmjwpw

Steps to reproduce

1. Open overlay, expand comboBox menu
2. Shrink viewport so at least a part of comboBox input would be under the right panel (then menu will be visible)
3. Expand viewport so non of comboBox input would be under right panel (menu will be hidden)

ComboBox_bug.mp4

Additional information

We are using version 1.43.0. This fix would be appreciated in V1.

[gretanausedaite]

Hi!
Thanks for submitting an issue.
Your request to add it it V1 is noted and we are discussing it within the team.

[SStalciuss]

The problem is here:

iTwinUI-react/packages/iTwinUI-react/src/core/utils/components/Popover.tsx

Line 85 in 7640e83

modifiers: [

This would solve my issue https://github.com/atomiks/tippyjs/blob/master/MIGRATION_GUIDE.md#if-you-were-using-boundary but you are setting a modifier with name 'preventOverflow' so the one that I pass in probably gets ignored. Adding additional property to options rootBoundary: 'document' fixes it, so you probably need to merge passed modifiers with your own.

If that fix makes sense, let me know and I could contribute too.

[r100-stack]

Thanks for trying this out. I tried implementing your example.

I think you have to pass your modifiers in popperOptions and not directly in dropdownMenuProps (L32 of overlay-model.tsx). Also, I think you had a typo. On L29, you had boundry instead of boundary. Here is the corrected L29 & L32 version:

But even with modifying your dropdownMenuProps as above or even manually passing options: {rootBoundary: 'document'} in preventOverflow instead of our options of options: { padding: 0 } near L85 of Popover.tsx, it gave the same problem as your video.

Could you confirm if your approach actually worked on your end? We too will try to get your code to work, or also look for a another fix since that didn't work.

[SStalciuss]

Well previously I somehow managed to fix it by changing how the modifiers are passed.

Now the object look like this:

I thought it should look like this (and it helped):

But I can't get it to work anymore and modifiers should automatically get merger according to this:
https://popper.js.org/docs/v2/faq/#how-do-i-set-modifier-defaults-and-allow-them-to-be-overridden

If you changed modifiers to be like in the second photo and it didn't help, then probably that is not the cause.

[mayank99]

@SStalciuss So from what I understand, changing the modifiers in Popover.tsx#87 in your node modules like this did not help?

-        { name: 'preventOverflow', options: { padding: 0 } },
+        { name: 'preventOverflow', options: { padding: 0, rootBoundary: 'document' } },

Maybe you can tell us a bit about your real world scenario then? We might be able to come up with a different solution.

[SStalciuss]

Sadly, it didn't.

My problem is the same that I reproduced in here https://stackblitz.com/edit/react-ts-pmjwpw. I have a right panel that has a button inside of it. That button opens a modal that has fixed position, so it is always visible until it is closed. That modal has a combobox. But if combobox is not behind the right panel, the content is hidden.

[mayank99]

I think this might be because your modal is a child of the right panel. You could try using a portal to place it near the root of your app. If you use the iTwinUI Modal, this will be automatically handled for you.

Does that fix it?

[SStalciuss]

Yes this would solve the issue, but elements with fixed positions are always visible, so the contents of the ComboBox should never be hidden. This workaround shouldn't be required.

[mayank99]

It's true that these workarounds shouldn't be required but that's the reality right now. Is there any reason you don't want to use a portal? It was designed specifically for these cases. Also, in #783 we were investigating providing a way to disable all hiding, but no luck. Worst case, you could override our css to unhide it, but that's a worse workaround than using portals imo.

Apart from that, there isn't much we can do here as we rely on tippyjs and popper, both of which have unresolved bugs and have stopped shipping updates. In our next major version, we plan to migrate from tippyjs to floating-ui, hopefully that will fix it. We'll likely change the API to be more modular too, allowing toggling every plugin if possible.