Components: Support blocking scroll on all scrolling containers via Overlay ScrollStrategy

[luke-emmental]

Bug, feature request, or proposal:

cdk overlayConfig scrollStrategies.block() not working

What is the expected behavior?

I expected It function block other scrollable at active overlay.

What is the current behavior?

Partially acted
app serve -> working in only chrome
prod build -> not working in any browser

What is the use-case or motivation for changing an existing behavior?

Which versions of Angular, Material, OS, TypeScript, browsers are affected?

os: macOS Sierra v:10.12.6
"@angular/animations": "5.2.8",
"@angular/cdk": "5.2.4",
"@angular/common": "5.2.8",
"@angular/compiler": "5.2.8",
"@angular/core": "5.2.8",
"@angular/flex-layout": "^5.0.0-beta.13",
"@angular/forms": "5.2.8",
"@angular/material": "5.2.4",
"@angular/material-moment-adapter": "5.2.4",
"@angular/platform-browser": "5.2.8",
"@angular/platform-browser-dynamic": "5.2.8",
"@angular/router": "5.2.8",
"core-js": "^2.4.1",
"hammerjs": "^2.0.8",
"rxjs": "^5.5.6",
"web-animations-js": "^2.3.1",
"zone.js": "^0.8.19"
"@angular/compiler-cli": "5.2.8",
"@angular/language-service": "5.2.8",

[jstuth]

I'm experiencing similar issues while setting scrollStrategy of a MatDialog. It just won't work....
i create my dialog the following way:

const dialogRef = this.dialog.open(EditAddressComponent, {
      panelClass: 'fullscreen-dialog-on-small-screens',
      data: this.company.address,
      scrollStrategy: this.overlay.scrollStrategies.block()
});

The background view is still scrolling. :(

[jstuth]

Somehow, the BlockScrollStrategy seem only to work, when window width is above 959px.
Is this related to some media breakpoints, since 959px is exactly what i use?

[croso-df]

I'm having the same issues when using the cdk-connected-overlay as this:

<ng-template cdk-connected-overlay
              [cdkConnectedOverlayWidth]="200"
              [cdkConnectedOverlayOpen]="isOpened"
              [cdkConnectedOverlayOrigin]="overlayOrigin"
              [cdkConnectedOverlayPositions]="connectedOverlayPositions"
              [cdkConnectedOverlayScrollStrategy]="overlayScrollStrategy"
              (backdropClick)="closeItemsBlock()">

and then I set overlayScrollStrategy to:

this.overlayScrollStrategy = this.overlay.scrollStrategies.block();

The overlay will still allow scrolling though. My workaround was to enable the backdrop and remove the background color from the backdrop so that it doesn't render dark.

<ng-template cdk-connected-overlay
              [cdkConnectedOverlayWidth]="200"
              ...
              [cdkConnectedOverlayHasBackdrop]="true"
              cdkConnectedOverlayBackdropClass="foo-cdk-backdrop-class">

I know it looks like a nasty workaround, but well, makes the trick for now.

[wojofe]

Experiencing scroll propagation issues with MatDialog as well, in a somewhat erratic fashion even (resizing the browser window and re-opening the dialog produces differing results).

When I scroll down inside the dialog, the dialog scrolls to its end. When I scroll down inside the dialog again while the dialog is poised at its scroll-end, the page in the background scrolls. When I scroll outside the dialog, the page in the backgroud scrolls.

Opening a MatDialog with scrollStrategy: overlay.scrollStrategies.block() makes no difference at all.

[mscudlik]

same issue with mat-select, neither block() nor noop() stop the automatic scrolling

[wojofe]

Bump. Please make block() work again.

[siddiq-rehman]

It was working fine in v7.. Now it is not :(

[mmalerba]

Can someone provide a stackblitz example demonstrating this?

[wagnermaciel]

Closing because this issue has been inactive for 2 weeks or more after follow up was requested.

[amaust82]

This is not working for me as well, here is a stackblitz showing an example of my issue.

Edit: Clarification that it is the issue I'm having, not necessarily the above examples.

[blended-ideas]

@wagnermaciel

Can we reopen this?
Since a stackblitz issue has been given.,

[jelbourn]

@crisbeto it looks like the block scroll strategy only deals with top-level scrolling and not other scrolling containers on the page. Did we do that intentionally? I don't remember the reasoning from the time.

[crisbeto]

Yes, that was intentional since it was unclear what would happen if a scroll container was placed inside an overlay that blocks scrolling. Historically we didn't really need to block scroll on any other containers, because the overlay backdrop prevented users from interacting with the elements.

[jelbourn]

Got it. Since this is working at least as intended, I changed this issue to a feature request.