Repro:

1. Go to https://arturjanc.com/cgi-bin/coop/navigation-history.py?coop=same-origin (on Nightly with the browser.tabs.remote.useCrossOriginOpenerPolicy flag enabled)
2. Click on "Same-origin no-COOP"
3. The address bar will temporarily lose the HTTPS lock icon until navigation happens, resulting in a visible jump when the page loads.

Note that the same thing doesn't happen on a navigation without COOP (https://arturjanc.com/cgi-bin/coop/navigation-history.py?coop=none -> "Same-origin no-COOP") or on other navigations that don't replace the browsing context group (https://arturjanc.com/cgi-bin/coop/navigation-history.py?coop=same-origin -> "Same-origin with COOP).

It's probably related to bug 1552012 - which also looses the HTTPS lock between navigations.

This seems to be working fine for me now with the latest nightly that has the fix for bug 1552012. Anne, could you confirm too so we can close this as resolved?

FWIW it still reproduces for me in 69.0a1 (2019-07-03) (64-bit) on Linux.

It's somewhat easy to miss, but I recorded my screen and slowed down the recording and it clearly shows the address bar losing the lock icon which also ends up shifting the text around (this is on macOS). I'm not necessarily convinced this should block MVP, but it's not a great experience for sure.

Interesting!

It seems like when we do one of these process switches through the HTTPResponseProcessSelection mechanism we do some weird visual stuff, hiding the busy indicator in the tab bar and doing a temp. lock hide. The particular code which would need to keep this working is SessionStore.navigateAndRestore.

Interestingly, we do set a pending flag on the tab as we're flushing session restore data (https://searchfox.org/mozilla-central/rev/040aa667f419932adf425d92c7438f03230ad96b/browser/components/sessionstore/SessionStore.jsm#4170), but gets cleared before we do the restore (https://searchfox.org/mozilla-central/rev/040aa667f419932adf425d92c7438f03230ad96b/browser/components/sessionstore/SessionStore.jsm#4295). This status is cleared after the restore operation is complete, and a message has been sent to tell the content process to begin restoring.

This also could be caused by some delay in the content process. When SessionStore:restoreTabContent is sent to content, it tries to resume the redirected load by ID (https://searchfox.org/mozilla-central/rev/040aa667f419932adf425d92c7438f03230ad96b/browser/components/sessionstore/ContentRestore.jsm#188-192). However, this message is likely to arrive in the content process before Necko has finished re-connecting the channel into the new process. This means that the actual load-resume process is delayed until the channel is ready (https://searchfox.org/mozilla-central/rev/040aa667f419932adf425d92c7438f03230ad96b/docshell/base/nsDocShell.cpp#13264)

I'm guessing the fix for this will involve some work to keep the throbber going for longer, and also to ensure nsDocShell is in a loading state after the call to resumeRedirectedLoad has been called, but before the actual channel has been connected and hooked up in the target process.

Mike, do you know (or know who would know ^_^) what controls these visual elements and what would would be required to ensure they don't flicker in this situation?

I can't reproduce in mac and linux. WORKFORME?

I still see some kind of flash that I don't see when clicking the first link. It's very minor though and I don't see the lock icon moving anymore.

I tried on today's Nightly and I also can't reproduce this anymore, at least the lock icon jump. I think we can close this bug.

I also don't see the bug anymore.
Thanks all for verifying!

It's somewhat hard to see, but due to about:blank being rendered the experience is a bit janky and there's much more of a change than with the initial navigation where only a couple bits change. To me this appears like a brief flash.

Per discussion with Nika this would be hard to fix and it's probably not worth blocking MVP with this, but it does seem like something we eventually need to address.

(To be clear, this still blocks resab, just no longer directly.)

Per team discussion this will not block shipping.