-
Notifications
You must be signed in to change notification settings - Fork 1.4k
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
Not rendering correctly in modal dialog #335
Comments
I only get this issue in Chrome. Firefox and IE11 are OK. It's a bit intermittent ... Playing with the width of the browser while the modal window is opened will turned the issue on and off. Setting a z-index on the bootstrap-switch-wrapper fixes the border on the left side, but not on the right side. If you're looking for a live example of this issue you can look at https://assessment.digitaljourney.co.nz/ (click on one of the quadrant of the Get Started circle to bring up the modal window) |
@maxime-rainville in your example, i don't get the possible look'n'feel issue. all seems fine to me. |
Here is the code that would show the issue. (problem only occurs in Chrome as far as I know)
|
I'm getting the same problem as maxime-rainville when using bootstrap switch inside of a Bootstrap 3 modal. The sliding mechanism or the code's that aligning the content of the switch is off by just 1 pixel to the left, leaving a bit of green from the ON section visible, and none of the right border visible. My other switches outside of modals are fine. FYI I've also added some CSS to remove the blue border from appearing in the switch's focused state. |
I had a similar issue where my left border wasn't rendering properly. Try adding the following: .bootstrap-switch {
-webkit-transform: translateZ(0);
-ms-transform: translateZ(0);
transform: translateZ(0);
} This seemed to fix it for me within a Bootstrap 3 modal. |
@jurgenvo @maxime-rainville @guanxun asserting that this issue is directly related with the modal is inaccurate, if not even misleading. also, i could not reproduce the issue as it has been explained. |
I also have a problem here. It may be reproduced here: When the modal is opened, the two switches are in the "ON" Using Chrome version 39.0.2171.65 m |
@adrianscott83's solution worked for me perfectly. |
I also ran into this problem. After single-stepping through the initialization of the Bootstrap switch with a debugger, I have a theory about the cause. The problem appears to be caused by logic in _initWidth that tests the visibility of an element called $wrapper. This element must be visible for the system to properly compute the handle width and label width. If $wrapper is not visible, the system sets an interval timer for 50ms and tries again later. Notwithstanding the 50ms re-try, the main execution continues; however, subsequent logic fails because the system needs the handle width value early in order to compute the switch container margin. If this value is undefined, the button is rendered as ON irrespective of state. The reason that this is related to the modal appears linked to the animation. In the initial phase of the animation, the visibility test for $wrapper fails causing the system to bypass the calculation of the handle width. Because this value is undefined, the system doesn't properly compute the margin offset, which causes the button to render in the ON position regardless of the actual state. Note that at this point the DOM is in a "bad" state, because the CSS classes (e.g., boostrap-switch-off) contradict the visible switch state. It appears that I can circumvent the problem by delaying initialization of the Bootstrap switch 200ms. I considered actually waiting until the modal animation was complete (using event shown.bs.modal) but if you wait until the modal is completely visible, you'll see the switch visibly change, which isn't ideal in my case. Please take this analysis with a grain of salt, I've just started using Bootstrap Switches in earnest. It would be great if others could confirm or refute my findings and post here. |
@sotarules there is a fix to be released in |
LostCrew, thanks so much. I tried release 3.3.0 (I could not find 3.2.3) and it does fix the problem that I have reported. However, FWIW I think I found a different problem in 3.3.0. The problem has to do with the skip parameter that can be supplied to API function "state". When set to true, the documentation indicates that skip will defeat the switchChange event. On 3.3.0, I started getting the switchChange event whenever I called the "state" function, even when I supplied skip true. I checked the source code and I think I found the cause: in _elementHandlers change.bootstrapSwitch, you'll see the following instruction: return _this.$element.trigger("switchChange.bootstrapSwitch", [state]); In 3.2.2, this instruction was subordinated to condition if (!skip), but in 3.3.0, the instruction is no longer conditional, it is now the very last line of the event handler and is executed unconditionally. I have circumvented this in my own code but I wanted to bring it to your attention. |
thank you @sotarules for the detailed description. |
Yes, it was as it was needed to properly handle multiple radio switches... How can we solve both the issues? |
i think only an additional flag can do the trick. what's your call? |
let's discuss about it over #411 |
When using the switch in a modal dialog, it is not rendering everything the way I would expect.
This is what I get:
I'm missing the border on the right and I don't want to see the blue of the ON side when the switch is turned off.
How could i fix this?
Thanks for the help!
The text was updated successfully, but these errors were encountered: