Here's another repro: https://jsfiddle.net/rom791fa/2/

Note this also repros on Chrome 60.0.3112.90 stable.

I strongly encourage that this bug be reprioritized.

Note that scrollIntoViewIfNeeded continues to work as expect (see my repro)

As an additional aside, when the document gets in this state, reloading, ctrl-shift-r reloading, and closing then opening the tab doesn't fix the issue.

Re#1, calling scrollIntoView on the yellow box ("you shouldn't see me!"), it is expected that it'll scroll the "parent" box. overflow: hidden prevents user scrolling only, scrollIntoView is programmatic so it will allow scrolling even though the overflow is hidden. Similarly, setting scrollLeft and scrollTop is also allowed on overflow:hidden. This is well established behavior and interoperable so we wont change it.

Taking a closer look, it seems that this is a bug on the page itself. The element with id "keep-us-running" is `position: absolute; bottom: -100px`. The body is overflow: hidden so we can't scroll down but it does cause overflow. As mentioned above, this allows programmatic scrolling. If you remove overflow: hidden from the body you'll notice that we can actually scroll the page so I think this is WAI.

But we're calling scrollIntoView on "I'm a thing that you might not see."

The expected behavior is to just scroll that one element into view.  Only its immediate scrollable parent should scroll.  Not all possible parents.

scrollIntoView is recursive and tries to make the Element appear at the top of the viewport, scrolling all parents until that's the case or it reaches the viewport and can't. In this case, we try to scroll the child container so that the "thing" is of its scroller. Since there's only a bit of overflow, we can't get it to the top of the container. We now try to scroll the parent scroller so that "thing" ends up at the top of the viewport. In this case, we can't either as there isn't enough overflow but we scroll a bit. If I make the body element very tall (height: 3000px), clicking scrollIntoView will scroll it to the top.

Wouldn't it make sense for the implementation to not attempt to scroll elements that are set to overflow:hidden?

Once the page gets in this state, there's no way for the user to fix it (apart from opening up Chrome Developer Tools and manually changing the elements' scrollTop).

It's unfortunate in this case but the spec is clear that overflow: hidden must be programmatically scrollable: https://drafts.csswg.org/css-overflow-3/#valdef-overflow-hidden

Changing this might have compat impact by breaking existing content and would certainly have interop impact as all browser behave the same today. Interop is most important here since, even though the behavior may be unintuitive in some situations, if it breaks in the same way across browsers authors will see it and work around it.

Thanks for explaining things and not just talking me down!

You're right, I see the exact same behavior in FireFox.