Skip to content

Fix positioning of suggestion dropdowns

Erwan Rouchet requested to merge fix-suggestion-dropdowns-position into master

Closes #906 (closed), #955 (closed)

I had a look at how Bulma does its dropdowns, modals, navbar menus, etc., experimented with PortalVue and vue-simple-portal to position the dropdown using position: absolute from the <body> element (which required handling all kinds of window resizes, zooms, element resizes, etc. using the ResizeObserver and a ton of other hacks), etc. only to find out after a very long time that overflow, overflow-x and overflow-y set to anything other than visible caused the issues that originally led to using position: fixed. This took an awfully long time to troubleshoot and I am now going insane.

For the FilterBar, the final change is to remove overflow-x: auto, which just means that typing very long strings in the element name filter can look a little strange. The FilterInput is changed to have a relative position on an element that is completely invisible, to let the dropdown position itself starting from the top-left corner of the <input /> element, making everything simpler.

For the SearchableSelect, the component hidden behind the MLClassSelect, the changes are a little weirder. There are no is-relative classes or position: relative properties, because the Bulma control already sets position: relative by itself. So I added the same position: absolute as for the FilterInput, and ran into two issues:

  • In the CreationForm and the selection classification modal, the modal used when creating new elements in non-batch mode from the InteractiveImage, the dropdown was kept inside of the modal, unable to display all of its options, because the Bulma modal, modal-card and modal-card-body classes all have some CSS overflow set to auto or hidden. This occurs in all browsers for the CreationForm, but the selection classification modal works properly under Chrome 🤷

    Overriding this would imply potentially breaking every single <Modal> of the frontend, and I already broke enough things here, so I instead added a isFixed property to the SearchableSelect which allows to selectively restore the current position: fixed. This works in this particular case, because the CreationForm is already designed to not have any scrolling, unless you use something like a 320×240 screen.

  • In the DetailsPanel, where most of the current issues with the dropdown have been found, the dropdown is unable to have a width that exceed the input's. That means that for classes with very long names such as HORAE, there is a ton of line wrapping and the dropdown sometimes overflow the entire page and is unreadable.

    While this is kinda annoying for long class names, this also means that this MR accidentally fixes #906 (closed)!

    I worked around this by just making the ML class input longer, taking the full width of the details panel.

Edited by Erwan Rouchet

Merge request reports