Narrow bisect info:
https://chromium.googlesource.com/chromium/src/+log/6f32734610f76a586f81b1cf3fa6df17cec131f7..400e90126213561c94c377ee786ab34d5b4ffe40?pretty=fuller&n=30

Suspecting: 497613 ?
Kindly help to reassign if this is not related to your change.

Deleted: Expected_Settings.mp4 487 KB

	Expected_Settings.mp4 487 KB View Download

Adding blocker label, please undo if not the case.

Removing release blocker because it doesn't affect functionality.

The change in rendering was due to fixing a bug in Blink that some overflow clips were applied to positioned descendants when they shouldn't. 

Reassigning to michaelpg@ who worked on MD Settings animation before. Feel free to reassign. I'll offer assistance in CSS too.

The basic structure of the page (roughly) looks like this:
<style>
#container {
  position: relative;
  overflow: auto;
}
#card {
  box-shadow: ...;
  overflow: hidden;
}
.iron-selected {
  position: static;
}
settings-subpage {
  position: absolute;
}
</style>
<div id="container">
  <div id="card">
    <settings-subpage class="iron-selected">...</settings-subpage>
    <settings-subpage>...</settings-subpage>
  </div>
</div>

Only the currently selected subpage will be position:static, this is because we only want to count its layout overflow as scrollable contents.

Subpages that are fading out will have position:absolute, not counted as scrollable contents for being out-of-flow. Now the problem is that having position:absolute implies #card is no longer its containing block, thus its overflow clip no longer applies.

Adding position:relative to #card will workaround the clip leak, but I'm not sure it is what the UI designer intended. There is still a noticeable glitch when the animation starts, that the fading-out subpage jumps up, due to resetting scroll position of #container prematurely.

Oops, didn't see this. Is it still occurring?

Reassigning since I'm not working on Settings anymore.

Scott, it looks like this would be eliminated by changing the animations to fades. What's the timeframe on that change?

I can't reproduce this on ToT. We could do a bisect and find which CL actually fixed it.

Regarding changing the animation to fades and changing how they work in general (separate scroll containers), like https://cs.chromium.org/chromium/src/chrome/browser/resources/md_extensions/view_manager.html, I think it is worth doing, but realistically this would require a lot of work to plug into Settings, and it is unclear whether we will get to it anytime soon.

Can't repro +1, closing as fixed. Please reopen if issue still persists.