Also repros on 65.0.3325.146 on Linux, so presumably this is cross-platform.  Raising priority-- if it's a simple fix, maybe we can merge to M66.

FWIW, Scroll anchor restoration isn't turned on for M65. Root layer scrolling is an unlikely culprit for the same reason.

I can repro this on Linux 67.0.3365.0 but was unable to repro on Windows Canary. 

Focusing <input> should lead to scrollIntoView():
LayoutObject::ScrollRectToVisible
HTMLInputElement::UpdateFocusAppearanceWithOptions
Document::SetFocusedElement
...

so one hypothesis could be that we are not setting the focused element properly in some cases. But the weirdness this theory fails to explain is that a) why do we even end up at a different scroll position, and b) why is it behaving differently on windows.

I could try and run a bisec and see if there are any clearer clues on what might have caused this.

FYI I can reproduce this bug by just right-clicking the link in step 2) and opening in a new tab.

I can repro this on Windows Canary 67.0.3368.0.  Maybe try again? 

Agreed about the "Open in link new tab" repro steps-- happens to middle click as well.

This seems broken since as early as 55.0.2881.0 (Developer Build) (64-bit).

I did some digging into this and found that the root cause is

a) "autofocus" on first <input/>
b) Strange (incorrect?) AbsoluteBoundingBox() for the <input/> when autofocus occurs.

The AbsoluteBoundingBox() of <input/> is different when we load the page first and after the reload from chrome://restart (or alternatively as open in new tab by right clicking the link).

So this to me seems like a Layout bug.

Nice progress-- adding Layout component per comment 7.

Do you plan to keep looking, or should we find an owner in the layout team?

I am not quite familiar with layout so I think finding an owner in layout team should be more efficient.

I also forgot to mention a third factor with this bug which is the use of external CSS stylesheets on the page. Removing the links seems to resolve the issue (tested on a local server).

So all in all, my understanding is that there is some races due to loading CSS and layout (which might be quite normal and expected) which together with autofocus leads to the wrong behavior.  

chrishtr@, can someone from the layout team take a look at this one?

Will do.

I found the following:

1. The scrolling is indeed due to autofocus.
3. During "load" of the OOPIF sub-frame, the autofocus attribute is noticed
and a task is put on the event queue for it.
4. The task calls Element.focus()
5. At this time, layout is actually dirty because the lifecycle has not started
for the sub-frame.
6. Element::focus() calls UpdateStyleAndLayoutTreeIgnorePendingStylesheetsForNode
to address situations such as #5.
7. There is another layout that happens on the sub-frame after #6.
8. The lifecycle for the OOPIF sub-frame is *never run* until the tab containing it is
shown. This is not true of its parent frame, which does get a lifecycle run.

It seems clear that putting a task on the event queue during page load is not a reliable
heuristic. However, I suspect that #8 is actually the proximate cause of this bug.
Is it expected that OOPIF sub-frames in background tabs don't get lifecycle updates?
I did verify that the OOPIF sub-frame is *not* throttled in the LocalFrameView::ShouldThrottleRendering sense.

-> ekaramad for next steps to find out why OOPIF sub-frames inside of 
background tabs don't get these lifecyle updates even though it appears the
parent does. I consulted with kenrb and it seems this is not expected.

panicker@: Can you help with comment 14?  Sounds like OOPIFs might not be getting lifecycle updates in background tabs.  (Ehsan, feel free to take this back, but I'm guessing you're out until Tuesday.)

Given the timing, I think we'll probably target M67 for this instead.

I'll take a look.

+altimin

chrishtr@ - could you confirm the following:
1. "not getting *lifecycle updates* in background tabs" refers to these states:
https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/DocumentLifecycle.h?l=49 
(sorry "lifecycle" is super overloaded in Blink)

2. which blink task queues (types) contain these lifecycle tasks? or where do they get queued? (posttask call will give a hint)

3. For the autofocus task is question - I think this is the one? https://cs.chromium.org/chromium/src/third_party/WebKit/Source/core/dom/Document.cpp?l=6943
If so, it is getting scheduled on the pauseable task-queue (task type: user-interaction)
There should be no throttling here that I'm aware of for background.
altimin@ -- any other ideas?   

over to chrishtr to answer above questions, then we can look at this from scheduler side.

I mean that LocalFrameView::UpdateAllLifecyclePhases is not getting called for the
OOPIFed child.

The autofocus task is getting scheduled.

LocalFrameView::ScheduleAnimation is in fact getting called, which ends up calling
SetNeedsAnimate on the proxy.

altimin - could you take a look from scheduler side as why LocalFrameView::UpdateAllLifecyclePhases is not getting called in background?

altimin@: Friendly ping.  Would you be able to take a look per comment 20?  We'd like to make sure that LocalFrameView::UpdateAllLifecyclePhases is working for OOPIFs.

skyostil@ or haraken@, can you help with comment 20 while altimin@ is OOO?  Thanks!

Lifecycle updates are driven by BeginFrames, which are completely paused for background tabs for efficiency reasons, so I think that part is working as expected here. The lifecycle update should happen when the tab is foregrounded again. Is that not happening here?

Re #23: that is correct, the OOPIF is not receiving a BeginFrame after
being foregrounded.

Friendly ping.  What's the next step towards fixing this?  Is there a BeginFrame fix needed?  Thanks!

Another friendly ping on this.
altimin@ what's the next step here?

Ping: this is marked as a P1, is there an update?

creis@: I can't repro this in 68.0.3440.106 - is this fixed?

(Just getting back from OOO.)  I can still repro this using the original steps on 68.0.3440.106 and 70.0.3534.0 on Windows, so this is not fixed.  bokan@, which platform were you testing on?  I'm curious why it didn't repro for you.

Is there anyone that can help with this, if altimin@ doesn't have the bandwidth?

Sami could you triage?

Hmm, maybe I did something wrong - I can now repro with Linux 70.0.3528.4. Maybe I missed the flag or something.