Really important issues! Why you have to not using this approach!

[librisius]

I'm sorry for my English, I use the initial translation because I'm so tired testing this approach. If something is not clear for you, ask me I'll fix it later.

So...

This solutation doesn't work:
http://luxiyalu.com/scrolling-on-overlay/
Description:
1. A common problem
Description: the Approach works only in this case lost the ability to track the scroll event on the window object, due to "reset" of height of the body (equal to the height of the browser's window):

html, body {
height: 100%;
}

2. iOS Problem, Android partly
Description: Inside of the unit .background-content you can't use the property -webkit-overflow-scrolling: touch, what enables to smooth scrolling (without the initial iOS "clumsy" scrolling) and normalization of the scroll when focusing inputs (more info: http://stackoverflow.com/questions/25596960/issues-with-touch-scroll-on-ios-when-focusing-inputs). If you add the property, then scrolling will be through the pop-up for no scrolling blocks ( the blocks with fitting content in the visible area completely).

.background-content{
height: 100%;
overflow: auto;
}

3. The problem is only on iOS
Description: Inside of the .background-content or body (as the body element the property is inherited to the element .background-content and including others in it) when you use the property -webkit-overflow-scrolling: touch there is a problem with the overlay layers ( the z-index property ). If inside the .background-content element is... for example a block .header (styles listed below), when you open the pop-up the .header gets under a pop-up, despite the fact that its z-index bigger than the z-index of the pop-up.
Insight: replace .header from the .background-content or delete -webkit-overflow-scrolling: touch from body

html, body {
height: 100%;
}

body {
-webkit-overflow-scrolling: touch;
}

.overlay {
position: fixed;
top: 0;
left: 0;
z-index: 1;

width: 100%;
height: 100%;
}

.overlay .overlay-content {
height: 100%;
overflow: scroll;
}

.background-content {
height: 100%;
overflow: auto;
}

.header {
position: fixed;
top: 0;
left: 0;
z-index: 9;

width: 100%;
height: 60px;

background-color: red;
}
<div class="overlay">
 <div class="overlay-content"></div>
</div>
<div class="background-content">
<div class="header"></div>
</div>

Minor cons:

1. Inside of the .overlay-content in browsers with a visible scroll bar (like windows' Chrome) those two scroll bars are visible always when the pop-up is active

.overlay-content {
height: 100%;
overflow: scroll;
}

Insight: the approach works more or less stably without using -webkit-overflow-scrolling: touch and your plugins allow you to handle scroll event inside the .background-content element instead of body

[mihaibogdan10]

+1 to what librisius says.
More simply said, you are no longer scrolling the document body, but rather an element inside of it. This breaks behaviors such as the iOS Safari menu hiding when scrolling down, so this solution is a no go.

[stratboy]

I found another problem in a special (but I guess common) use case: fixed header.

If you have a fixed header, despite the position it has in markup, it will appear above the scrollbars in Safari (at least 10.1.1) and explorer 10/11 (anche probably the other explorers and Edge). More generally I think the 'bug' is of safari and explorer.

The thing that triggers the bug, is the overflow auto and height: 100vh (if you need to) on background-content.

[englishextra]

html.your-lightbox--open.
body.your-lightbox--open {
	overflow: hidden;
	-webkit-overflow-scrolling: touch;
	touch-action: auto;
	height: auto;
}