-
-
Notifications
You must be signed in to change notification settings - Fork 6.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Many display problems with Select2 4.0.1 #3970
Comments
This appears to be a bug when there is a margin set on the body and the So this is definitely related to c9216b4, because it only affects statically positioned elements. |
I had a possibly similar issue in which the dropdown portion appeared slightly lower and to the right of where it should have been. Do you think this is related? If so, what additional information, if any, would be helpful? For the time being I just papered it over by tweaking the positioning in my custom CSS overrides, but obviously I'd prefer a better solution. |
For anyone running into this issue, it would be useful to have the output for the following two statements (executed in your browser console, F12 usually): document.body.style.position and $(document.body).offset() On the documentation website, I get the following output Which explains why the dropdown is lining up fine there. This will allow me to confirm that the issue is actually with the offset caused by margins on the body (or the dropdown parent). |
I misremembered -- it's slightly above and left of where it should be. Anyway, here's the console output from those commands:
|
I'm getting the same issue. Here's the output:
|
Same problem here...
And yes, it's positioned 65px too high, "left" position is correct. The control looks correct if I remove the page margin - but then the page looks broken. If I wrap it like this:
The problem still appears - even if the page itself does not have a margin. This works, though:
|
Same problem:
|
For me, 4.0.1 opens the dropdown and immediately closes it whenever I click on the select. Reverting to 4.0.0 fixes the problem. |
This is probably a separate, unrelated issue. If you can create a jsbin/jsfiddle that reproduces the issue and a new ticket describing the issue, we can handle the bug. |
It seems like the same issue. Also seems to be caused by CSS problems. Here's a fiddle: https://jsfiddle.net/hacf7fdy/1/ Click on the select without holding down the mouse and it will immediately close again (Chrome 46, no idea if it happens on other browsers). |
It's the same issue. Had the same thing here and it's caused by having one of the list items at the location of the mouse as soon as the drop down opens and when you "mouseup" select2 thinks the item has been selected and closes. |
Ah, you're right. I forgot how we handle events in the dropdown. The dropdown is getting placed beneath the mouse, and the |
Same here - noticed this because of an item being selected when the dropdown opens, as other people seem to have found.
|
Same here. Dropdown is appearing too high.
|
This fixes an issue with non-static parents (ones that were relatively or absolutely positioned) where the dropdown would be offset by the offset of the parent, so it would almost never line up. This fixes the problem by removing the offset when the parent is not statically positioned, which is what we used to do in older versions of Select2. This closes #3303. This closes #3614. This closes #3672.
This adds a regression test that verifies the problem with positioning the dropdown when the parent is a statically positioned element that still has an offset. This could typically be seen if the body element has an offset, which unfortunately it almost always does because of the default user stylesheet in browsers. This was not caught during pre-release testing because all of the test pages reset the margins and padding on the body element. This regression test verifies that the offsets that should be set for the dropdown are calculated correctly. These were surprisingly difficult to do because of how the offset is calculated using different positioning techniques. These tests are for #3970
same issue appear with fixed header template |
Note that this issue should be fixed with the latest master if you manually recompile the assets. It will be included in the upcoming 4.0.2-rc.1 release. |
This adds a regression test that verifies the problem with positioning the dropdown when the parent is a statically positioned element that still has an offset. This could typically be seen if the body element has an offset, which unfortunately it almost always does because of the default user stylesheet in browsers. This was not caught during pre-release testing because all of the test pages reset the margins and padding on the body element. This regression test verifies that the offsets that should be set for the dropdown are calculated correctly. These were surprisingly difficult to do because of how the offset is calculated using different positioning techniques. These tests are for select2#3970
There was a commit that landed in 4.0.1 that fixed positioning for non-static elements, which are commonly used for the custom `dropdownParent` option, but broke positioning for statically positioned elements, commonly used in almost every other case. That commit was select2@c9216b4 This fixes the positioning issues caused by that commit by properly calculating the offsets for statically positioned parents. Statically positioned parents are unique, because the offset for the dropdown must be calculated based on the closest element that is non-statically positioned. Otherwise, the offset for any statically positioned parent other than the body will be considerably higher than it should be, resulting in the dropdown being offset by a large amount. The offset parent for the body element is the html element, which is why this works for both the body element and any custom parents for the dropdown. This would not be needed if the parent wasn't customizable (as seen in Select2 3.x) because you will never need to offset the body element if it is statically positioned, because the html element almost never has an offset. This also fixes JSHint issues within the tests added in the last commit. This closes select2#3970 This closes select2#3639
Hello,
Since version 4.0.1 (no problem with version 4.0.1-rc1), even the simplest examples are not displayed correctly on all browsers (latest Chrome / Firefox / Safari at least): the dropdown is not displayed under the selector.
Here is an example: https://jsfiddle.net/michaelperrin/zxu8pxn3/1/ (clicking on the selector shows the dropdown, but it is displayed too much on the left).
The text was updated successfully, but these errors were encountered: