I suspect this may be related to Scroll Anchoring. I showed the effect to Yash and he suggested it may be the case.

This article is behind a paywall.  Are you able to repro on a locally saved copy?

Yes. I can on my phone. I turned off the "Scroll Anchoring" in chrome://flags but it still repros. Yash mentioned there is a bug in flag implementation which cause it to now actually disable. Happy to test other things.

I have attached a recording of how it looks.

Deleted: 2016_10_03_15_47_36.mp4 520 KB

	2016_10_03_15_47_36.mp4 520 KB View Download

BTW, I can bypass the paywall by searching it on Google (perhaps in a separate profile) and getting to the link.

I can repro this using dev tools mobile emulation.

Confirmed that we're making an incorrect adjustment.

Looking further..

hmmm, this is an interesting one.

So the page has a header that becomes fixed when the user starts to scroll past it. They are not compensating for the jump caused by the change in flowness, so we expect our flowness suppression change from  issue 641814  to disable anchoring, but that fails.

Upon taking a closer look..

This is WSJs top nav experience: hide the header when the user scrolls past it, and only show it when the user is scrolling in the upward direction. They first hide the header using display:none, and then attach position:fixed to it. The two things happen in different layout passes, and we don't suppress scroll anchoring in the former case. This is what causes the incorrect adjustment, as it did before the inflowness change suppression.

Minimized-repro: https://jsbin.com/pajadeg/quiet

Should we suppress anchoring for changes to the 'display' property to any element in the scroller? I worry that there's probably other cases like these?

This site jumps a lot without scroll anchoring when you hit the boundary point. I wonder if we should just try to contact WSJ and ask them to fix their site? A fix that prevented jumping would also serve to make it work with scroll anchoring.

I suspect if we tell them a small change they could make to fix the jumping that we could get them to fix this.

Yeah its a good idea to reach out to WSJ to fix the jumping issue.

I am more worried about other sites that may also do this in the wild who we can't reach out to.

We probably need a more scaleable solution here, WDYT?

I also tested on my N5 running M55 with the Scroll Anchoring flag set to enabled and have been unable to reproduce it.  Here are the steps I'm following:
1. Open an incognito window
2. Navigate to google.com and search for "http://blogs.wsj.com/washwire/2016/09/26/donald-trump-on-not-paying-taxes-that-makes-me-smart/"
3. Select the appropriate result and wait for it to complete loading
4. Scroll far enough down so that the navbar is out of view

Correct Behavior: Scroll stays at mid-page
Incorrect Behavior: Scroll snaps to top
Actual Behavior: Scroll stays at mid-page

This appears to be fixed. I'm not sure how. ymalik, you willing to do a bisect so we can be sure it's something we changed?

I can still repro this on ToT. 

I suspect that the reason you weren't able to repro this is due to the subtle difference in behavior depending on the screen width.

You will notice that if the screen width is big enough, there is a carousel right under the header (see attached image). I found this CSS for the carousel: 
@media (max-width: 660px)
.hide4 {
    display: none;
}
i.e., hide the carousel on small screens.

If there is a carousel, this bug doesn't happen (AND the page doesn't jump because of the header changing in-flow ness / visibility). If the carousel is hidden, the bug happens. 

Can you verify that this bug is still repro able by making the window smaller?

Upon further investigation, I found that there is also the following CSS in the page:
.subType-unsubscribed .mega-nav.mobile.stick-mobile-nav+* {
    padding-top: 109px;
}
This translates to "apply padding-top: 109px on the element right after the header element when the header becomes out of flow". 
i.e., the page is in fact trying to compensate for the jump caused by the inflow change (contrary to what I said in comment 6). 

The reason this does nothing on small screens is because the element right after the header is the carousel, which is hidden.

So to fix this, I think all WSJ would have to do is add a placeholder div right after the header to which the compensating padding will apply.

Deleted: WSJCarousel.jpg 57.3 KB

	WSJCarousel.jpg 57.3 KB View Download

I believe that fixing this is on WSJ's roadmap and there isn't anything for us to do here.