How can we reproduce this bug?
On reveal modal docs page
What did you expect to happen?
To open modal and nothing more
What happened instead?
When I open modal the width of content is changing
Test case
Open any modal link
Give us a link to a CodePen or JSFiddle that recreates the issue.
http://foundation.zurb.com/sites/docs/reveal.html
Hello!
I have a solution for this bug!
To stop this width jumping we need to remove overflow: hidden from
body.is-reveal-open {
overflow: hidden;
}
We need to add more data-options to choose from:
data-fixed: true or false
data-scrollable: true or false
This one's will be very useful.
Thank you very much!
If I can help you with that, I will be very happy! :)
Not sure what you're referring to about width, i'm not seeing anything odd with the widths.
If Modal opened the background content shift a some pixels bit to the right, this is annoying for most customers. On http://foundation.zurb.com/sites/docs/reveal.html have a look at the right Menu or the Boxes in the main content. The hole content seams to stretch (OSX, Firefox).
body.is-reveal-open {
overflow: hidden;
}
does not really helps. jquery ui has the same Problem(not on Demo but in real Projects). The only Modal i know without content shift is the bootstrap one http://getbootstrap.com/javascript/#modals-examples. I think the Problem is the scrollbar. Foundation have a default one, bootstrap only if needed.
I hope this description helps to find the bug.
Solution
get Bodyoffset: var bodyOffset = window.innerWidth - $(window).width();
if grater 0 add on open: $('body').css('padding-right', bodyOffset + 'px');
remove on close: $('body').css('padding-right', '');
If you have sticky elements like header do it for this Elements too.
Yes the problem is scrollbar it disappears because of the overflow: hidden property on body.
Note: If folks aren't seeing this bug, it's probably because their OS/browser uses overlaid scrollbars. This'll be a problem for, say, some Linux systems, certain Windows versions, and other browsers whose scrollbars take up part of the window width.
thanks @andycochran, I'm not certain there's much we can do for this one, outside of forcing a scrollbar to appear on the html element while concurrently removing one from the body. This is not a nice solution, and it doesn't seem there is a nice solution to this problem after a bit of stackoverflow searching. Any ideas in user land?
html {
@include breakpoint(medium) {
margin-left: calc(100vw - 100%);
margin-right: 0;
}
}
My Solution from three post before works nice.
I'll talk to the team about implementing one of these.
Going to test @andycochran's solution, mostly need to ensure it doesn't interfere with off-canvas.
Oh, it won't work in IE9 because IE9 doesn't support viewport units.
The CSS fix creates a weird padding bug in IE9/10, so it might not be the right solution.
Oh, it won't work in IE9 because IE9 doesn't support viewport units.
Erm, http://caniuse.com/#feat=viewport-units says IE9 only doesn't support vmin.
@cvrebert Yep, you're totally right. I'll think before I type next time :)
Either way, I need to do further testing to figure out what causes this padding bug I encountered. So far I've only done basic testing in our documentation—when I have time I'll put together an isolated test case.

Ack! Just reread the post about the technique I proposed. It says:
My scrollbar trick is only intended for centered content, something that may not have been clear.
So that's where the padding bug comes from. This method ain't gonna work.
I have a work-around. This will the hide the scroll bar for the reveal-overlay which actually doesn't work since there's nothing to scroll and then replace it with the body scroll bar that is already there.
This may have downsides, I'm not a developer so I don't really know much.
Add this code to your app.scss file
.reveal-overlay {
@include breakpoint(medium) {
overflow-y: hidden !important;
}
}
body.is-reveal-open {
@include breakpoint(medium) {
overflow-y: visible !important;
}
}
The CSS fix above is not optimal becuase it doesn't prevent scrolling on the body.
I fixed this issue by adding right-padding to body equal to the width of the scrollbars using this snippet:
http://stackoverflow.com/a/22707309/1162844
The only issue with this is that I had to apply it to to my nav as well since it was fixed position. Not sure how this could be made a universal solution if users need to choose extra elements to apply it to.
This was my fix if it helps anyone:
// List of elements which need to be padded
var paddables = [
{ el: $('body') },
{ el: $('#nav') }
];
// Cache the original padding values
$.each(paddables, function(i, e){
e.padding = parseInt(e.el.css('padding-right'));
});
var scrollbarSize = scrollbarSize(); // Cache the value once
$(window).on('open.zf.reveal', function(){
// Add space on the right equal to the width of the disappearing scrollbar
$.each(paddables, function(i, e){
e.el.css({ 'padding-right': scrollbarSize + e.padding });
});
});
$(window).on('closed.zf.reveal', function(){
// Remove the added space
$.each(paddables, function(i, e){
e.el.css({ 'padding-right': e.padding });
});
});
I think this "bug" might be too app-specific to fix.
This problem is described in many places, this one suggests that the bug does not exist in Foundation 5: http://foundation.zurb.com/forum/posts/38019-scrollbar-page-jump-on-reveal-open
That may be worth looking into. Also, if there are other modal implementations that don't exhibit this behavior then surely it should be fixable.
Problem still remains for me in 6.2.4 (best described with @8149).
None of these fixes worked for me.
What about getting rid of body.is-reveal-open { overflow: hidden; }, and instead preventing body from scrolling via JavaScript?
// disable scroll
$.fn.disableScroll = function() {
window.oldScrollPos = $(window).scrollTop();
$(window).on('scroll.scrolldisabler',function ( event ) {
$(window).scrollTop( window.oldScrollPos );
event.preventDefault();
});
};
// enable scroll
$.fn.enableScroll = function() {
$(window).off('scroll.scrolldisabler');
};
I'll try a pass on the js solution for 6.3
Probably not the most elegant solution, but managed to get it to behave with the below:
$(window).on('open.zf.reveal', function(){
var $browserWindowWidth = window.innerWidth;
var $bodyWidth = document.body.clientWidth;
var $winPadding = $browserWindowWidth - $bodyWidth;
if($browserWindowWidth !== $bodyWidth ) {
$('body').css('padding-right', $winPadding);
}
});
$(window).on('closed.zf.reveal', function(){
$('body').css('padding-right', '0');
});
Any additional fixed elements will need the padding adding and removing. Like I said not really elegant, it's more for anyone turning up between now and an official solution.
If we go with a JS solution, wouldn't it be better to prevent scrolling than to mess with unpredictable cross-browser styles?
My simplest css solution:
body.is-reveal-open {overflow: auto !important; height: auto; position: relative;}
.reveal-overlay {overflow: initial !important; position: absolute;}
@g00dwin css solution works for me too.
Pushing this out to 6.3.1, but I'm leaning towards the JS solution of disabling scrolling, enabled/disabled by an option... anyone have strong opinions for or against?
This is what worked for me:
body.is-reveal-open {
overflow: auto;
}
Hey guys
Do we have any further updates on this. The problem does still remain in 6.4.1 I noticed yesterday.
I have no further updates - @codetheorist do you want to take a pass on the JS solution described in https://github.com/zurb/foundation-sites/issues/7831#issuecomment-256375323 ?
~Why is a JS solution preferred over a CSS one?~
I noticed that https://github.com/zurb/foundation-sites/issues/7831#issuecomment-258143665 jumps to the top of th e page.
I noticed that https://github.com/zurb/foundation-sites/issues/7831#issuecomment-211946929 prevents the scrolling of a long Reveal.
@andycochran Where do you call the functions that you define in https://github.com/zurb/foundation-sites/issues/7831#issuecomment-256375323 ? i.e., how you plug it into the Reveal hide/show?
@isapir I'm not sure where you'd plug that in. It's just an idea, just a chunk of code lifted from Stack Overflow for addressing this issue, but unrelated to Foundation.
@andycochran Thanks for clarifying.
@kball I opened a PR that resolves this issue, based on https://stackoverflow.com/a/13891717/968244 -- I tested it on Chrome, Firefox, and Edge on Windows, and Chrome on Android, and it seems to work well.
For the time being, you can see a working example at https://beta.100candles.com/items.htm (WIP) -- where each item thumbnail opens a Reveal.
Does anyone know where the Travis test cases are hosted? My patch works but the test cases need to be adjusted and ATM Travis shows that the test cases fail.
I have the issue with 6.4.3.
I have a kind of images gallery.
When I click on an image, a modal (reveal) is opened, and makes the content (gallery) scroll badly.
I want to prevent this ugly scroll.
Solution above has not worked for me.
Any news about?
@mica16 I have submitted a patch to fix this at PR #10583
Easiest solution with preserving correct scrolling functionality is just:
body.is-reveal-open {
padding-right: 17px;
}
Scroll-bar width is 17px, so just make sure that with opened reveal web page won't move.
Scroll-bar width is 17px
For which browser? Is that in the spec? Unfortunately I doubt it that all the browsers conform to the same width.
@isapir You were right! Scrollbar for each browser is different. So I tried just window.innerWidth - $(window).width() but this is a bad solution because (probably) with overflow: hidden, these values will be the same. So I used scroll-bar width solution (https://github.com/olmokramer/scrollbar-width.js/) and there is a nice working solution with preserve of scrolling functionality when the modal window have bigger height than window height.
$(window).on('open.zf.reveal', function() {
var scrollbarWidth = window.getScrollbarWidth()
$('body').css('padding-right', scrollbarWidth);
});
$(window).on('closed.zf.reveal', function() {
$('body').css('padding-right', '0');
});
Thanks for reply and warning 👍
AFAIK this issue was fixed with the patch that I provided #10583 which has been pulled in and will be available in the next release.
This issue should be reopened now due to regression from https://github.com/zurb/foundation-sites/pull/11065
See also comment at https://github.com/zurb/foundation-sites/issues/10791#issuecomment-377863960
@ncoden @DanielRuf @colin-marshall
@ncoden Do you want me to look into this issue or do you have someone working on it?
@isapir I am working on this. I have a working solution.
Excellent :)
On Sun, Jun 17, 2018, 2:08 PM Nicolas Coden notifications@github.com
wrote:
@isapir https://github.com/isapir I am working on this. I have a
working solution.—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/zurb/foundation-sites/issues/7831#issuecomment-397906694,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AA2Ek89Zen1LSRhuEkp4PE-vJ-Kt5J3Lks5t9sVJgaJpZM4HB13o
.
Most helpful comment
Probably not the most elegant solution, but managed to get it to behave with the below:
Any additional fixed elements will need the padding adding and removing. Like I said not really elegant, it's more for anyone turning up between now and an official solution.