Tested the issue on mac 10.13.3 using chrome reported version #66.0.3353.0.

Attached a screen casts for reference.

Following are the steps followed to reproduce the issue.
------------
1. Navigated to http://output.jsbin.com/somakus/27
2. scrolled both the blocks.
3. Did not observe any sticky 'header' and 'footer' blocks.

Note: Also observed same bahaviour in chrome stable #64.0.3282.167 and firefox.

reporter@ - Could you please check the attached screen casts and please let us know if anything missed from our side. Any further inputs from your end will help us in triaging the issue further.

Thanks...!!

Deleted: 816161@66.0.3353.0.mp4 2.8 MB

	816161@66.0.3353.0.mp4 2.8 MB View Download

Deleted: 816161@64.0.3282.167.mp4 1.3 MB

	816161@64.0.3282.167.mp4 1.3 MB View Download

Only reproducible when "Experimental Web Platform features" is enabled in chrome://flags

Bisect info: 530924 (good) - 530933 (bad)
https://chromium.googlesource.com/chromium/src/+log/a805e7a8..1f05f166?pretty=fuller
Suspecting r530927 = e9aa1ff150cc50a295227f280d50a7b023938cbd = https://crrev.com/c/862082 by bokan@chromium.org
"[Reland] Add implicit rootScroller feature"
Landed in 66.0.3329.0

Confirmed by disabling the CL and observing the bug(?) is gone:
chrome --disable-blink-features=ImplicitRootScroller --enable-experimental-web-platform-features

I'm attaching a simplified test case:
1. open test.html
2. scroll over the left column continuously
3. observe the numbers on the greenish background at the top
EXPECTED: the first number doesn't change during the middle phase of scrolling 
          e.g. 400, 200, 39, 39, 39, 39, 39, 39, -30, -230, -430
OBSERVED: the first number changes after each scroll wheel "tick"

Deleted: test.html 21.9 KB

test.html 21.9 KB View Download

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/8c76d1277b168775e75f53c06c7b9bde185fe276

commit 8c76d1277b168775e75f53c06c7b9bde185fe276
Author: David Bokan <bokan@chromium.org>
Date: Wed Apr 25 18:45:10 2018

Correct OverflowClipRect() for root scroller

When a layout object is the effective root scroller, the
OverflowClipRect uses the ViewRect rather than computing the padding box
as usual. This is because the padding box won't expand when the URL bar
is hidden.

Unfortunately in the root scroller case we forget to set the passed in
location. This patch adds that so the rect is in the correct coordinate
space. Additionally, this all works only if the box set as the effective
root scroller has no border since the OverflowClipRect uses the padding
box. I've updated the root scroller to ensure the padding box matches
the viewport rect.

Ideally we'd just return View()->OverflowClipRect - which does remember
to set the location - in LayoutBox but this could lead to an infinite
recursion as that calls LayoutBox::OverflowClipRect if the ViewRect is
empty. Thus, we call ViewRect directly.

Bug:  816161 
Change-Id: I2f622ff0c25e58373955e1d0e22d54e254e134ff
Reviewed-on: https://chromium-review.googlesource.com/1026517
Reviewed-by: Philip Rogers <pdr@chromium.org>
Commit-Queue: David Bokan <bokan@chromium.org>
Cr-Commit-Position: refs/heads/master@{#553678}
[add] https://crrev.com/8c76d1277b168775e75f53c06c7b9bde185fe276/third_party/WebKit/LayoutTests/rootscroller/position-sticky-rect-inside-root-scroller.html
[modify] https://crrev.com/8c76d1277b168775e75f53c06c7b9bde185fe276/third_party/WebKit/LayoutTests/rootscroller/set-rootscroller-before-load-expected.html
[modify] https://crrev.com/8c76d1277b168775e75f53c06c7b9bde185fe276/third_party/WebKit/LayoutTests/rootscroller/set-rootscroller-before-load.html
[modify] https://crrev.com/8c76d1277b168775e75f53c06c7b9bde185fe276/third_party/blink/renderer/core/layout/layout_box.cc
[modify] https://crrev.com/8c76d1277b168775e75f53c06c7b9bde185fe276/third_party/blink/renderer/core/page/scrolling/root_scroller_controller.cc
[modify] https://crrev.com/8c76d1277b168775e75f53c06c7b9bde185fe276/third_party/blink/renderer/core/page/scrolling/root_scroller_test.cc

bokan@chromium.org, would your comment about "no-border" mean that I would still encounter the bug if had an element filling the viewport with 'margin: -1px' and 'border-width: 1px'? Making the element scroll as the root scroller as it's padding box matches, but has a non-zero border-width value?

No the underlying bug is fixed by the above patch. It was just in fixing it I realized I wanted to apply the feature when the padding box matches the viewport size (i.e. if I made just the padding change, then yes, the bug would have occurred instead when you have `margin: -1px; border-width: 1px`). 

bokan@chromium.org way awesome! Now, if you have any insight into this comment about the root scroller, feel free to chime in. :D

-> https://bugs.chromium.org/p/chromium/issues/detail?id=825544#c4