alexclarke@ - could you PTAL?

Note that more OOPIFs will be seen in the wild with time.  For example in M63 the //chrome layer will start requiring isolation of accounts.google.com.  There will be no option to turn the additional OOPIFs via some flag (and even if there were a flag, I assume that it would be undesirable if //headless exercised different code paths than what end users of Chrome are using).

I am not familiar with how //headless and virtual time work, but it does seem to me that we do want to observe the same virtual time in all frames belonging to the same set of related browsing contexts.  In particular, we want to observer the same virtual time 1) across opener/openee tabs (i.e. across 2 render views) and 2) across all frames in a frame tree (i.e. across OOPIFs).  Therefore moving tracking of virtual time into the browser process seems to make sense to me.

We need an option to turn OOPIF off.

Does headless use a full desktop Chrome build, or is it a different content embedder, or something else?

There won't be a way to disable OOPIFs in full desktop Chrome.  (For example, they may be enforced via enterprise policy, via  issue 783842 .)  However, if headless is a separate build, it's possible there might be a way to turn them off in the short term.

It's important to get something working here in general, though, for the reasons lukasza@ mentioned-- having this diverge from actual Chrome behavior that users see would be a concern, and OOPIFs are becoming more and more common.

#3: Headless is a content embedder so I think we have the controls to disable OOPIF for now. That said, longer term we'd like to make sure headless and OOPIF play well together. Alex is putting together a summary doc of the issues we know of so far.

I think a very high level summary is that the better we make DevTools work with OOPIF the fewer problems we'll have in headless mode (with some notable exceptions like virtual time).

Thanks-- as a content embedder I'm hoping you won't be affected by some of the upcoming launches (which are mainly at the chrome/ layer).  Agreed that we should aim for better OOPIF support for DevTools and headless, and that it sounds like it's not imminently a problem.