Dropdown data-boundary option not working in scrollable column
#26512
Comments
|
Hi @jackmu95, you are right, since the To be honest I don't see why the col is relative positioned. @mdo what am I missing? |
|
First of all, sorry for my bad english :(. Hi @jackmu95, I think the library is ok. After analyzing your code, I´ve seen the following line:
I´m not an expert, but I think this is a bad practice. A col should be a col and no more. The framework is designed keeping this in mind. We use a div for a row and other div for the col due to the same reason. There are few cases where col and other classes can be together. I´ve forked your codepen with my implementation, i hope it could help you: https://codepen.io/koro-sempai/pen/PerKLE. If I´m not missing something, separating the col and the dropdown-container in two divs solves the problem :), achieving a dropdown-container with position: fixed (by default). This is just my opinion, I hope it does not sound arrogant :) |
|
@notaphplover You are right that it's bad practice to style columns directly but I couldn't come up with better markup for my concrete situation where I faced the issue. Here is a pen to show what I mean: https://codepen.io/jackmu95/pen/yjdzvy The general question here is as @andresgalante mentioned why |
|
@jackmu95 Ah, ok. Then it was a misunderstood on my part. I´m not able to answer that question, but maybe this thread could be helpful: #25254 |
|
@notaphplover Thanks for the investigation! There is already a PR too (#25255) but it got stuck. |
|
@jackmu95 You are welcome. Yeah, it would be wonderful ^_^ 👍 . |
Before this commit, when a dropdown overflew its container i.e. in the case of a long filter menu in modal The scrolling of that dropdown to get to Add custom Filter was impossible This was because dropdowns react pretty bad when contained in a relative positioned container twbs/bootstrap#26512 twbs/bootstrap#28513 !! After this commit, the btn-group that adds the relative positioning is forced into the default value This commit corrects what was initially corrected at odoo#37594 in v12.0. The incriminating commit that retriggers the issue is irrelevant because it is the refactoring of action manager but here it is: 40dd121
Before this commit, when a dropdown overflew its container i.e. in the case of a long filter menu in modal The scrolling of that dropdown to get to Add custom Filter was impossible This was because dropdowns react pretty bad when contained in a relative positioned container twbs/bootstrap#26512 twbs/bootstrap#28513 !! After this commit, the btn-group that adds the relative positioning is forced into the default value This commit corrects what was initially corrected at #37594 in v12.0. The incriminating commit that retriggers the issue is irrelevant because it is the refactoring of action manager but here it is: 40dd121 closes #39541 Signed-off-by: Aaron Bohy (aab) <[email protected]>
Before this commit, when a dropdown overflew its container i.e. in the case of a long filter menu in modal The scrolling of that dropdown to get to Add custom Filter was impossible This was because dropdowns react pretty bad when contained in a relative positioned container twbs/bootstrap#26512 twbs/bootstrap#28513 !! After this commit, the btn-group that adds the relative positioning is forced into the default value This commit corrects what was initially corrected at odoo#37594 in v12.0. The incriminating commit that retriggers the issue is irrelevant because it is the refactoring of action manager but here it is: 40dd121 closes odoo#39541 Signed-off-by: Aaron Bohy (aab) <[email protected]>
Before this commit, when a dropdown overflew its container i.e. in the case of a long filter menu in modal The scrolling of that dropdown to get to Add custom Filter was impossible This was because dropdowns react pretty bad when contained in a relative positioned container twbs/bootstrap#26512 twbs/bootstrap#28513 !! After this commit, the btn-group that adds the relative positioning is forced into the default value This commit corrects what was initially corrected at #37594 in v12.0. The incriminating commit that retriggers the issue is irrelevant because it is the refactoring of action manager but here it is: 40dd121 closes #39541 closes #39620 Signed-off-by: Aaron Bohy (aab) <[email protected]> Signed-off-by: Lucas Perais (lpe) <[email protected]>
Before this commit, when a dropdown overflew its container i.e. in the case of a long filter menu in modal The scrolling of that dropdown to get to Add custom Filter was impossible This was because dropdowns react pretty bad when contained in a relative positioned container twbs/bootstrap#26512 twbs/bootstrap#28513 !! After this commit, the btn-group that adds the relative positioning is forced into the default value This commit corrects what was initially corrected at odoo#37594 in v12.0. The incriminating commit that retriggers the issue is irrelevant because it is the refactoring of action manager but here it is: 40dd121 closes odoo#39541 Original-signed-off-by: Aaron Bohy (aab) <[email protected]> X-original-commit: 7f72b83
Before this commit, when a dropdown overflew its container i.e. in the case of a long filter menu in modal The scrolling of that dropdown to get to Add custom Filter was impossible This was because dropdowns react pretty bad when contained in a relative positioned container twbs/bootstrap#26512 twbs/bootstrap#28513 !! After this commit, the btn-group that adds the relative positioning is forced into the default value This commit corrects what was initially corrected at #37594 in v12.0. The incriminating commit that retriggers the issue is irrelevant because it is the refactoring of action manager but here it is: 40dd121 closes #39541 closes #39636 Original-signed-off-by: Aaron Bohy (aab) <[email protected]> X-original-commit: 7f72b83 Signed-off-by: Lucas Perais (lpe) <[email protected]>
When a dropdown is placed in a scrollable column (
.col) thedata-boundaryoption has no effect.As @rinick pointed out here this is due the columns
position: relative;property.Is this something Bootstrap or popper.js can/should fix or has the user to deal with it?
See: https://codepen.io/jackmu95/pen/XqBWwx
The text was updated successfully, but these errors were encountered: