We'd actually have to wait until min(FirstContentfulPaint, OnLoad) before showing the next page since it's theoretically possible for a page to not paint any content.

Let's be careful here, since we've had a series of URL spoof bugs reported where the old page puts up fake content to display as the new URL commits and is displayed in the omnibox.  Ken added a 4 second timer that clears any painted content if the new page hasn't shown up yet (see  issue 497588  for when it was added, but also  issue 648117  and  issue 672847  for where similar security bugs).

Note that in those cases, the renderer was unresponsive, which was a mitigating factor.  It would be much worse if the previous document was still able to run script or remain interactive after the new document has committed.

I'm also concerned about this being exploited, as all it takes is a slow response from the site that the attacker is after to create a URL spoof.

Can we think of other ways to make the user experience better other than leaving the old page in place?

This sounds like it could potentially run into issues with the stale graphics timeout.

The omnibox URL is updated when the navigation commits, at which point the previous page's DOM is no longer in existence. The expectation is that it could still be scrollable on the compositor thread?

A problem there is that I recently modified the browser process to ignore any compositor frames that were generated for content that existed before the last navigation commit (see bugs linked by Charlie). This might not preclude showing the old page greyed out, but I think it means it can't be scrollable.

The restrictions are important because of phishing risk. Even with the old document unloaded, the problem is that an attacker can, for instance, navigate to google.com to get a trustworthy URL in the omnibar, but prevent the new page from successfully painting, while the attacker's page is still visible on the screen with a big warning "Your Google account has been compromised, call 1-XXX-XXX-XXXX for assistance."

re #3: Greying out the old page might be okay as long as the timeout is kept (i.e. the new page gets 4 seconds to get to FCP). I don't think we can easily reconcile keeping it scrollable, though.

Yes, we'll need to be thoughtful and careful about UI here both in terms of security and in terms of perceived loading speed. I'm confident that we can address them though.

Firstly, we absolutely should not change the URL bar to show the new site until we're actually showing the user the new site. Aside from security concerns, it would just be a confusing user experience.

There's lots of options we could explore though. Here's a couple ideas off the top of my head:
1. Change the URL bar to "Loading: facebook.com...". Not sure if that gets the right security tradeoff though.
2. Show a status bar (like we do on desktop) that shows "Loading facebook.com..."
3. Show a spinner-style UI that indicates that loading of the next page is happening, but don't actually show the next page. This might have some power and performance concerns though.

I'm sure there are other creative solutions that balance security, performance and user experience needs.

I still think the first step is to prototype the simplest behind a flag that doesn't do any of that and has the *definitely not shippable* security problem so that we can fishfood the experience ourselves to get a feel for whether it's actually a better user experience or whether it would feel like pages take forever to load.

If we find it to be a better user experience, then we can have discussions about what the right UX is.

What are the semantics WRT script execution in the not-yet-shown document? Today, we have so-called "provisional local frames" for supporting OOPIF, but they are basically inert until they are actually committed in the frame tree. In fact, we were planning on removing this infrastructure once PlzNavigate ships: the concept of a 'provisional local frame' that's sort of attached, but not really, has proven to be rather confusing in the past.

I was picturing that they'd load as regular pages. Script would execute and all. I guess there's a question about what to do if the page starts making sound. I guess we could say that the new page paints at min(FirstContentfulPaint, OnLoad, MakesSound, DoesAModalAction). I know that's a little hacky and gnarly, but it still seems worth prototyping.

Do you think that would add the same sort of technical complexity that provisional frames do?

Yes, I have big concerns about that, similar to Daniel's.  What if the page doesn't have visible side effects but scripts another window (e.g., the opener)?  Or the other window tries to script it?  Which document is actually considered to be in the frame tree at the time-- the new, not yet displayed one, or the previous, about to be replaced one?

I think the safest approach we can take is to come up with some visual the browser process can draw before the first compositor frame from the renderer arrives for the new document. Such a graphic can be used instead of the white space and have visual indication that the document is loading. 

I think all other attempts to activate the new document and still show artifacts from the old one will lead to high complexity and lots of security/functional bugs.

+aposner for potential overlap on your plans around speed perception.

kenjibaheux@: Was there a reason you removed me in comment 12, or was that unintentional?

Ah, definitely not intentional. Sorry! m_ _m

Marking available.