Search and Top Navigation
#10082 open bug ()
Opened June 02, 2014 01:22PM UTC
Last modified July 30, 2015 01:09AM UTC
Selectmenu items remains visible and fixed while scrolling dialog content
| Reported by: | matiax | Owned by: | |
|---|---|---|---|
| Priority: | major | Milestone: | none |
| Component: | ui.selectmenu | Version: | 1.11.0-beta.2 |
| Keywords: | Cc: | ||
| Blocked by: | Blocking: |
Description
Inside a dialog when start scrolling it's content, if a selectmenu was opened, the items container shows like a fixed element.
Steps:
1) Click on select menu to show items
2) Using the mousewheel, start scrolling down
Result: Items remain visible, fixed and on top of the rest of the content
Expected: Maybe the items must hide or move along with the select menu.
The same happens with the datepicker widget
Attachments (0)
Change History (6)
Changed June 02, 2014 02:11PM UTC by comment:1
| _comment0: | We should listen for scroll events and if the target is an ancestor of the widget, then we should close the popup. → 1403651591496562 |
|---|---|
| _comment1: | We should listen for scroll events and if the target is an ancestor of the widget, then we should close the popup. \ \ ---- \ \ Datepicker: #8223 → 1403651632451191 |
| priority: | minor → major |
| status: | new → open |
| summary: | Selectmenu items remains visible and fixed while scrolling dialog conten → Selectmenu items remains visible and fixed while scrolling dialog content |
Changed June 13, 2014 08:25PM UTC by comment:2
Changed July 29, 2015 11:45PM UTC by comment:3
Possible solution: http://jsfiddle.net/Y9KWN/5/
Follow the same instructions as before, only this time click on the FIX button first.
What I did is to wrap the span.ui-selectmenu-button with a div.ui-selectmenu, and also put div.ui-selectmenu-menu (with a little css change) inside the same div.
It bothers me that that div.ui-selectmenu-menu is appended to the body instead of being along side span.ui-selectmenu-button. I think with this approach both elements are siblings inside the same container wich to me makes more sense that having them both separated.
The only thing left to be changed is that the items are overflowed outside the width of the span.ui-selectmenu-button
Changed July 29, 2015 11:56PM UTC by comment:4
Replying to [comment:3 matiax]:
What I did is to wrap the span.ui-selectmenu-button with a div.ui-selectmenu, and also put div.ui-selectmenu-menu (with a little css change) inside the same div.
That negates all uses of the appendTo option.
Changed July 30, 2015 12:45AM UTC by comment:5
Yes, but even with that option the problem persist. And both elements, button and menu, are not under a unique container for both of them. Besides, I think it's more intuitive to apply the widget directly and expect to generate a structure similar to my proposal than setting a special option to move one of both elements at the same level that the other.
Don't you agree with this reasoning?
Here is what happens with only setting "appendTo": http://jsfiddle.net/Y9KWN/6/
Changed July 30, 2015 01:09AM UTC by comment:6
Replying to [comment:5 matiax]:
Don't you agree with this reasoning?
No. There are literally years worth of attempts, use cases, and knowledge that went into the current API.
Here is what happens with only setting "appendTo": http://jsfiddle.net/Y9KWN/6/
We know what happens. That's why this ticket exists.
We should listen for scroll events and if the target is an ancestor of the widget, then we should close the popup.
Other widgets:
Autocomplete
Datepicker: #8223