Documentation for Dialog
says:
A blocking Dialog disables all other actions and commands on the page behind it.
but scroll events are not intercepted. I think we should disable them, too. Especially on mobile this looks funny because the translucent overlay scrolls a bit out of view, revealing the page behind.
http://dev.office.com/fabric#/components/dialog click Dialog blocking
=> Open dialog
and try to scroll the page using wheel or touch.
PageUp / PageDown also scroll the page even while the blocking dialog is shown.
Fixing this isn't as straight-forward as I thought. We could do something like this when opening the dialog (and undoing when closing, of course):
document.body.style.overflow = "hidden";
document.body.style.paddingRight = `${getScrollbarWidth()}px`;
overflow hidden prevents scrolling, setting the padding prevents "jumping" from having the scrollbar suddenly hidden.
Since the scroll
event cannot be canceled, another approach might be to intercept events like onWheel
, onTouch*
on the Overlay
and prevent/stop them.
@dzearing @mikewheaton Any thoughts?
It's an interesting problem because it requires reaching outside of the component, and sometimes even the Fabric wrapper component itself, to modify the body
. Although it does seem reasonable in this case because even if Fabric doesn't take up the whole page, the Dialog does.
Yeah, reaching outside initally concerned me, too. However I don't see another way so I'm also leaning towards that direction. Maybe a small helper disable/enablePageScrolling
, a ms-noPageScroll
class to apply to body, and that padding on the element.聽
Yep this is a wonky issue. Probably doing what you suggested might be an answer, but not fullproof.
@ThomasMichon do you have ideas?
Should be resolved.
Most helpful comment
Yeah, reaching outside initally concerned me, too. However I don't see another way so I'm also leaning towards that direction. Maybe a small helper
disable/enablePageScrolling
, ams-noPageScroll
class to apply to body, and that padding on the element.聽