tylerr514@ Thanks for the issue.

Tested this issue on Windows 10 and Mac OS 10.13.5 on the reported version 67.0.3396.87 and the latest Canary 69.0.3457.0 by following the steps given above.

On clicking on the blue links in the above site, cannot observe jump of the iframes.
Checked issue on enabling/disabling Strict Site Isolation and is not reproducible either.
Attached is the screen cast for reference.

Request you to check and confirm if anything is missed from our end in triaging the issue.

Also request you to retry the issue on a new chrome profile without any flags/extensions and update the thread with the observations.

Thanks..

Deleted: 852141.mp4 5.6 MB

	852141.mp4 5.6 MB View Download

Sorry for not being clear as to what I meant.
But in your video it showed the iframe moving up around 5-10px.
Btw I'm not talking about the scrolling (that is intentional).
Pay close attention to the site contained in my window frame.
Use Dev tools to confirm that the iframe is relocated after clicking on a link.
Btw everything (of relevance) inside of the window frame (ie: not the titlebar), for that particular window, is an iframe

Thank you for providing more feedback. Adding the requester to the cc list.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Able to reproduce the issue on Mac 10.13.3, Win-10 and Ubuntu 17.10 using chrome reported version #67.0.3396.87 and latest canary #69.0.3461.0.
This is a non-regression issue as it is observed from M60 old builds. 

Hence, marking it as untriaged to get more inputs from dev team.

Thanks...!!

The reason is that, for some reason, the <div> that contains the iframe (.windowContent) has a scrollHeight that's larger than its offsetHeight. This means it's "scrollable" so when you try to scroll the fragments into view, it causes this div to scroll too (you can reset the jump with scrollTop=0). If you make the container overflow: visible (and another container higher up too) the issue goes away.

It's strange though because the only thing the <div> contains that takes space is the iframe and that's the same size as the container div according to dev tools. I can't find why scrollHeight is ~6px larger than the iframe. Changing the line-height property seems to affect this but I can't get them to be equal. Unfortunately I couldn't boil this down to a minimized repro but someone from layout team should have a look.

The iframe is display inline so vertical alignment comes into play, even if no other content is present. This is how inlines work in blink and is not always what one would expect.

Changing the vertical-align, line height, font size, or overflow property avoids the problem.

Thank you for the feedback.
Was able to reproduce successful mitigations (changing the display value).
I would also like to note that, even though it is considered aberent behavior from one's expectations, it should not be discarded as a caviate of blink behavior.
I will leave this "issue" opened, in case if anyone has anymore to add to the discussion, or if the chromium team wishes to close it.