Material-components-web: When the user opens `select`, and scroll, the screen will move.
Bugs
What MDC-Web Version are you using?
v0.14.0
What browser(s) is this bug affecting?
All browsers
What OS are you using?
Windows 10
What are the steps to reproduce the bug?
https://material-components-web.appspot.com/select.html
What is the expected behavior?
When the user opens select, the body's scroll bar should not be scrolled.
What is the actual behavior?
When the user opens select, and scroll, the screen will move.
Any other information you believe would be useful?
Shyam-Chen
All 25 comments
I can confirm this is incorrect behavior for the web. The native select (and therefore our CSS-only version) captures the scrolling. The JS enhanced version should do this as well to align with the native a11y features.
Garbee
on 29 Jun 2017
I can confirm this bug too! A similar issue was occuring for the drawer (#777) where the page could be scrolled even if it is open. Maybe a similar fix could do the trick?
touficbatache
on 29 Jun 2017
@touficbatache is correct that the solution for mdc-drawer is probably the correct solution for mdc-select.
Filing as a bug!
amsheehan
on 29 Jun 2017
No news? It seems that the JS enhanced version still suffers the "scroll bug".
roncapat
on 27 Oct 2017
Feel free to submit a PR to fix it! @roncapat You can take a look at https://github.com/material-components/material-components-web/pull/807/files to see how the fix for the drawer was done.
touficbatache
on 27 Oct 2017
Thank you for the reference of that fix. I'll try.
roncapat
on 27 Oct 2017
The fix is way easier than that for the drawer IMHO. No need to add/remove classes, just a quick CSS fix. Maybe I'm wrong, but it works.
roncapat
on 27 Oct 2017
To me, this is not closed. What do we do if the selection is inside another scrollable element other then body? Then the issue still persists! Also, I think it is not a good user experience to prevent a user from scrolling the page, just because he/she opened a selection field.
Imho the best would be to use position: absolute instead of fixed on the selection and adjust the calculations for positioning (which needs adjustment anyways because of wrong position calculation in dialogs).
j-o-d-o
on 4 Dec 2017
I think it is not a good user experience to prevent a user from scrolling the page, just because he/she opened a selection field.
Well, this is exactly how native select elements work. We should reflect that more than anything. It's for accessibility.
Garbee
on 4 Dec 2017
I think it is not a good user experience to prevent a user from scrolling the page, just because he/she opened a selection field.
Well, this is exactly how native select elements work. We should reflect that more than anything. It's for accessibility.
Are you sure? I think native selection will close the selection when you start scrolling its parent and will not lock scrolling.
j-o-d-o
on 4 Dec 2017
I'm positive at least on Windows and Linux. If you're using Mac OS then perhaps they have a different interaction there.
Garbee
on 4 Dec 2017
Did you try the codepen? I tried on Win 7 & 10 with the latest Chrome and latest Firefox and opening a selection field does not prevent me from scrolling the parent element, but rather closes the opened selection.
The MDC Demo page actually shows the currently different behavior quite nice: https://material-components-web.appspot.com/select.html. While the JS enabled selection blocks scrolling the body, the CSS only selection closes on scrolling the body.
j-o-d-o
on 4 Dec 2017
For me, I open the select element, then move the cursor over the body and scroll. Things stay as they are, no changes. Perhaps my test on Windows was with a different example previously which had something to make incorrect. I think since these are native interface pieces it kinda depends on the OS itself and some settings within that could change the effects for a11y as well.
This is something where we should try to adhere to the OS-level semantics as much as possible. Not force things one way or the other outright because we think we know better.
Which means the task here would be to investigate each OSes native handling of this and undergo adhering to it within the JS enhanced solution.
Garbee
on 4 Dec 2017
Okay, I think I know what you mean... maybe?:
Cursor is above the selections -> the parent element does not scroll
Cursor is outside the selections -> parent scrolls and on scroll, the selection closes
I am all for staying as close as possible to native behavior, that is what the user is used to. I am not sure where I want this discussion to lead, I guess I just want to stress, that let's not forget about the Javascript MDC-Selection implementation as it think is far from perfect :-).
j-o-d-o
on 4 Dec 2017
Cursor is outside the selections -> parent scrolls and on scroll, the selection closes
On Linux at least which I can test right off this is not the case. The selection does not close and the parent does not scroll. The select node has complete focus and until it is triggered closed by a user gesture it remains that way and visible.
Garbee
on 5 Dec 2017
I tried it on Linux and finally understand the behavior you describe.
There are just two main differences to the current mdc-select behavior:
1) The scrolling is locked, but the scrollbar is not hiding. With overflow: hidden, the scrollbar hides and then shows again which results in these ugly jumps of page width
2) The current mdc-select only locks scrolling on the body. If the mdc-select is inside another scrollable parent it doesn't work anymore.
Just things to keep in mind.
j-o-d-o
on 11 Dec 2017
When I got interested in this component first, I noticed how wrong was the fact that the drop-down overlay was visually disconnected from its selector when scrolling, it was just wrong, and tried to fix it. But I agree with you (and especially with the last message) that the implementation is far from perfect, and now there are other problems. Scrollbar bumps need to be fixed, they are annoying. Maybe I'll give a look if I can.
roncapat
on 11 Dec 2017
Maybe we should for example override wheel and touchmove events and avoid to play with overflow settings? any suggestions?
roncapat
on 11 Dec 2017
Hmm. I think for the time being, it would be much easier to mimic the default behavior on Windows where the select menu closes when you scroll outside of the menu opposed to the default Linux behavior (see discussion with @Garbee). So, listening to the onScroll event when the cursor position is outside of mdc-select__menu, I would close the select menu. Or maybe it is included in the event which element is scrolled, I am not sure right now. Opinions on that?
Thanks a lot for taking the time!
j-o-d-o
on 11 Dec 2017
Based on the discussion above, @lynnjepsen could you consider reopening this issue?
The page width flickering is the real issue.
MaterializeCSS library just use position:relative / position:absoulte for the selects - http://next.materializecss.com/select.html and no scrolling issues happens
kmmbvnr
on 27 Dec 2017
Closing this issue, since this is inherently handled by the native select in MDC Select now.
However, this would need to be addressed for #2552.
kfranqueiro
on 7 Jun 2018
Reopening this issue because it was reintroduced in PR #3949 and reported in issue #4450.
To avoid the dropdown menu getting clipped when an Enhanced Select is inside an element with CSS overflow set to hidden, scroll, or auto (e.g., mdc-dialog), we call MDCMenu.hoistMenuToBody():
However, this "solution" has an unfortunate side effect, which is that the menu becomes disconnected from the anchor element when the user scrolls:
I'm not sure if we can actually fix this, because the scroll event does not bubble, and a Select could theoretically have multiple scrollable ancestors other than <body>.
There might be a solution I'm not seeing, however, so I'll add this to our backlog to investigate.
acdvorak
on 28 Feb 2019
what about capturing the overflow attribute value from the parent element of the menu list upon open - store that on the "menu" - and set the parent element overflow to hidden as long as the menu is open (in most cases the parent would be the body but I guess that any parent could be handled that way) - when the menu has a closing event - then set the overflow setting back to its original state.
cintaccs
on 28 Feb 2019
another option is to create a cover element that covers the entire body/screen and launch the popup content on top of that cover element. Cover would have "display: block;" and background: rgba(255,255,255,0.0005);width: 100%;
height: 100%;position: fixed;
top: 0px;
left: 0px;
z-index: 9990;
any click action on the cover will close the menu. I have a solution like that for a similar popup menu and the benefit is that the parent(s) keep whatever overflow setting without re-sizing due to showing scroll bars or not. I.e. the cover takes over the scroll - and that is "hidden". The body or whatever content in the background keeps the original scrolling as is.
cintaccs
on 28 Feb 2019
With regards to follow-up issue, marking this as duplicate of #4541
abhiomkar
on 21 Apr 2019
Related issues
trimox
路
4Comments
m-alzam
路
3Comments
abhiomkar
路
3Comments
devshekhawat
路
3Comments
jimyhdolores
路
3Comments
Most helpful comment
I tried it on Linux and finally understand the behavior you describe.
There are just two main differences to the current mdc-select behavior:
1) The scrolling is locked, but the scrollbar is not hiding. With overflow: hidden, the scrollbar hides and then shows again which results in these ugly jumps of page width
2) The current mdc-select only locks scrolling on the body. If the mdc-select is inside another scrollable parent it doesn't work anymore.
Just things to keep in mind.