Material-components-web: Wrong position of opened Select inside Dialog component

[bmihelac]

What MDC-Web Version are you using?

0.11.1

What browser(s) is this bug affecting?

Chrome, Firefox, probably all others as well

What are the steps to reproduce the bug?

Add select component to Dialog and open it.

We also have a template on CodePen which we encourage you to use to create a reproduction of
the issue. The less time it takes for us to repro the issue, the less time it takes to verify and
fix it!

http://codepen.io/bmihelac/pen/qmvxjJ

What is the expected behavior?

Open choices in proper position.

What is the actual behavior?

Wrong position, shifted options as on picture below:

[yeelan0319]

Definitely not look right, thanks for filing.

[pgbross]

From duplicate issue #844

The simple menu underlying the select list is positioned using css position: fixed semantics with the calculations relative to the viewport. However if an ancestor, such as the .mdc-dialog__surface has a transform property set to something different from none then this ancestor is used as the container instead of the viewport.

Note this fault is not limited to within a dialog but wherever there is an ancestor with a transform property.

[pvamshi]

Is there a workaround or temporary fix for this. Thankyou.

[DBartsch]

Yeah .. I'd also be interested.

Possibly best would be to just move the menu to the body, give it an id and aria-controls on the parent

[abyr]

As a temporary fix it's possible to overwrite "top" and "left" with "inherit !important" on ".mdc-select__menu".

[thosakwe]

Still getting this bug. If I could help patch it up, that would be awesome. Just can't figure out what the cause is.

[j-o-d-o]

Is there actually a reason that the select menu is position: fixed? When scrolling the parent this seems really really bad. position absolute with mdc-select being position: relative seems much butter.

@thosakwe I think the problem is, that getBoundingClientRect() is not returning the correct value when some parent is scrolled. Or at least not the correct value with the current CSS styles.

My workaround for scrollable parents is this:

    .mdc-select{
        position: relative;
    }
    .mdc-select__menu{
        left: 0px !important;  
        top: 0px !important;
        position: absolute !important;
    }

Note: this always opens the menu from the first index. It's just a hack and might actually defet some behaviours that are explained in the offical documentation (e.g. calculation if menu overflows top or bottom and adjusting the position)

[JordyvA]

Same issue over here, and also the scrolling with an selectbox open is an issue.

[SVyatoslavG]

Same issue, please fix it.

[izakfilmalter]

I've done the following to get a fairly good ux:

.mdc-dialog .mdc-select {
  position: relative !important;
}

.mdc-dialog .mdc-select__menu {
  top: inherit !important;
  left: inherit !important;

  max-height: calc(100vh - 64px)!important;

  margin-top: 44px;
}

[mellogarrett]

Is there an actual fix coming for this? The work arounds are not ideal. This issue has been open for quite some time now.

[mellogarrett]

Actually, the positioning is correct in IE 11, but wrong in Chrome, Safari, & Firefox 🤔

[izakfilmalter]

Probably an IE bug, position: fixed is relative to any parent that has a
transform on it.

On Mon, Dec 18, 2017, 2:44 PM Garrett Thompson [e-mail]
wrote:

Actually, the positioning is correct in IE 11, but wrong in Chrome,
Safari, & Firefox 🤔

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/material-components/material-components-web/issues/719#issuecomment-352537076,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFmimr-y8_K7KqdoQAAe5G3c_t4UEJlwks5tBsCbgaJpZM4NmO0q
.

[mellogarrett]

transform: translate(0,0); screws up the positioning of the opened menu.

Edit: on all browsers _but_ IE 11

[devgianlu]

Setting transform: none on the .mdc-dialog__surface element fixed the issue for me.

[piotr-cz]

Still a problem in @material/select v0.29

[kmmbvnr]

I agree with @j-o-d-o The only correct div based select implementation should be based on position:relative/absolute styles. That's how select is implemented in the MaterializeCSS library.

[izakfilmalter]

I think mdc needs to have a special div inside of body where it places all elements that need to overlap. You get into issues with overflow: hidden and with any transform with both select, and dialog. This would resolve that, can still use the regular position technique, but you lose so many bugs like this.

For instance, if we want to do any panel based ui, we are gonna use a transform for mobile performance. Which in turn screws up any selects inside of that panel. I used to work around this with the css only select, but now that's gone as well which is a big pain in the butt because the native ui for select on mobile is not bad, and in the old docs it was pointed out as being a better experience.

[piotr-cz]

I'd love to see the css-only Select component back that uses native <select> element.

There are too many things that are hard to work around when implementing similar functionality in JS (like container inside scrollable table), this issue is just one of them.
It's possible to add workaround for most cases but code becomes complex, library heavy and UI loses responsivity.

I've been through it before with _Select2_, now it's exactly the same with _MDCSelect_.

[PeteCrighton]

@izakfilmalter Thanks for your workaround! I used a margin-top of 7.5px, but that works quite well for me. Still an annoying bug …

[ixtli]

I don't know if this will help anyone, but I am including @material/select, @material/menu, and @material/list in my React 16 project. I @import all the MDC sass styles I am using in another SCSS file, and i was experiencing a behavior where the menu was showing up in the center of the window.

After a bit of puzzling and comparing the computed styles on the demo page ( https://material-components-web.appspot.com/select.html ) with my own, I found that .mdc-menu--open style was being applied on top of .mdc-select__menu on my mdc-menu component. This was resulting in postition: absolute instead of fixed. I ended up re-arranging my imports in my scss file from this:

@import "../node_modules/@material/select/mdc-select";
@import "../node_modules/@material/menu/mdc-menu";
@import "../node_modules/@material/list/mdc-list";

to

@import "../node_modules/@material/menu/mdc-menu";
@import "../node_modules/@material/select/mdc-select";
@import "../node_modules/@material/list/mdc-list";

and now it works.

I can't be exactly sure but this may explain why people were experiencing similar (but not exactly the same) behavior and correcting it by setting the position with !important. CSS is annoying.

[kmmbvnr]

I've got same inside drawer, even with transform: none style from .mdc-drawer--open

Fixed by

 .mdc-drawer__drawer {
      will-change: unset;
}

[r1cs1]

I've found two important notes in the w3 specs.

Will-change

If any non-initial value of a property would cause the element to generate a containing block for fixed-position elements, specifying that property in will-change must cause the element to generate a containing block for fixed-position elements.

Transform

For elements whose layout is governed by the CSS box model, any value other than none for the transform also causes the element to become a containing block, and the object acts as a containing block for fixed positioned descendants.

Thus it means the mdc-menu for the select component is going to be relative to the parent element that is alike mentioned above instead of the viewport, while the top; left; properties are calculated relative to the viewport instead of the transformed container. Same issue applies to a right side aligned mdc-drawer.

[rubenmendoza]

I have created a pen to reproduce this issue https://codepen.io/linear/pen/YazeQx

[j-o-d-o]

So with #2399 this issue technically is fixed too, right?

[abhiomkar]

This issue seems to be fixed in new version.

Closing this.