The issue also repros even if you navigate to the URL in an Incognito tab, which seems a little surprising, since I'd expect that to be isolated from any renderers the normal profile is running.

FWIW, opening the form link in an incognito window works fine for me.

Re #2: Have you checked that you have Isolator Irina configured, and then
opened a google.com tab before you open the form link?

I tried in a Guest profile on MacOS with 64.0.3282.167 and it worked fine.

wez@, can you capture a chrome://tracing trace with navigation category enabled? I wonder if it is more of a navigation issue than anything else.

Re #4: Interesting; I haven't tried it in a Guest profile.

I'm still able to repro the issue under Chrome Linux 64.0.3282.167, but it is intermittent.  Under ChromeOS 65.0.3325.65 and C66.0.3344.0 it still repros 100% reliably for me.

I've taken a "navigation"-only trace from Chrome Linux 64.0.3282.167, and attached it.

Deleted: trace_crbug814080_broken_form_signin.json.gz 266 KB

trace_crbug814080_broken_form_signin.json.gz 266 KB Download

Hit "save" too soon. :P

The trace has four attempts at the Sign-in. The first attempt succeeded; that was made in a Forms tab that was already open before the chrome://tracing tab. I closed that Forms tab, opened a new tab and loaded the Forms link in it, then tried three more times, all of which failed.

I can repro in an incognito profile of 66.0.3346.8 (Official Build) dev (64-bit) running on Rodete with strict site isolation enabled via chrome://flags.  The repro happened on the 2nd attempt as suggested by wez@ in #c6 above.

I can repro at ToT (r538171) without any cmdline flags (i.e. without --site-per-process or --isolate-origins;  also note that ToT/local/Chromium build should not be subject to enterprise policy).  I note that the repro was very flaky - I've tried around 10 times and the problem reproed only 2 times.  I also note that sometimes the loading of the sign-in page takes a few seconds (but when the problem reproed I am really sure that after clicking the tab actually stayed on the old page [rather than I just didn't wait long enough]).

I've also reproed at ToT with --site-per-process and in my very subjective opinion the repro was as flaky as without this flag.

Because of the repro flakiness I am hesitant to try other cmdline combinations (in particular, --disable-features=sign-in-process-isolation).

Just adding that for me the the issue repros consistently in Incognito mode on Chrome OS (66.0.3344.0) and this is without "Strict Site Isolation".
I also verified form task manager there are no OOPIFs involved.

alexmos: Discussing this offline w/ nasko@, it sounds like you're the best person to look into this and confirm whether it's related to Site Isolation, PlzNavigate or some other recent change - thanks. :)

I could consistently repro this on Linux ToT.  I think this is a race between a history same-document navigation and a cross-process navigation.

The forms doc does a HISTORY_SAME_DOCUMENT navigation, followed by a navigation to accounts.google.com.  The latter will create a pending RenderFrameHost with sign-in isolation (which at this point is on by default for everyone).  However, that pending RFH seems to be prematurely destroyed as part of DidCommitSameDocumentNavigation:

#2 0x7f1e5cb37a1e content::NavigationRequest::~NavigationRequest()
#3 0x7f1e5cb189cb content::FrameTreeNode::ResetNavigationRequest()
#4 0x7f1e5cb640f8 content::RenderFrameHostManager::CommitPendingIfNecessary()
#5 0x7f1e5cb63f7e content::RenderFrameHostManager::DidNavigateFrame()
#6 0x7f1e5cb3e893 content::NavigatorImpl::DidNavigate()
#7 0x7f1e5cb5078a content::RenderFrameHostImpl::DidCommitNavigationInternal()
#8 0x7f1e5cb5087a content::RenderFrameHostImpl::DidCommitSameDocumentNavigation()

--disable-features=sign-in-process-isolation will work around this specific case by not making the navigation to accounts.google.com cross-process, but this is a more generic cross-process nav issue that we need to fix; it doesn't seem right that CommitPendingIfNecessary() ends up being called as part of DidCommitSameDocumentNavigation().  I hear that clamy@ has some work in progress on this, so reassigning to her.

The race between same document navigation and cross-process navigation is known and being fixed as part of  issue 809488 . The CL was out for review today and hopefully will land sometime this week.

Is this a blocker for M64 and M65?

I don't think this should be a blocker, since it is an existing race exposed from the sign-in isolation work (isolating accounts.google.com), which has launched in M63. Given that we've received user reports of this in practice just now, I don't think it should be a blocker for M64 and debatable that it should be a blocker for M65 too.
In addition, the fix builds on newly refactored code, which is definitely not in M64, possibly not in M65 either.

The fix for the race condition landed in https://chromium-review.googlesource.com/c/chromium/src/+/925423.

I've confirmed that this is fixed on Linux ToT @544889.  Thanks, clamy@!