I think this might be a fission only bug, but I'll observe it some more and report back.

I haven't been able to reproduce it using mozregression tool while investigating bug 1662925.

Steps to reproduce:

1. Make sure the url you will be testing is one in your frequently visited list, I used https://web.telegram.org
2. Open a tab via shortcut (Command-T for me on Mac)
3. Quickly start typing the url and as soon as it pops up in the suggestions, press enter

expected: the page starts loading
actual: no visual indication that a page is loading (reload button is still active, has not changed state) and the page does not load, see attached GIF

NI-ing Neha as I'm not sure who should look at this.

Note that even though there is an update pending (as seen in the GIF), I updated firefox after recording this and it is still happening as of build 82.0a1 (2020-09-02).

(as I said in https://bugzilla.mozilla.org/show_bug.cgi?id=1662925#c1) Another way to check this, is for me to download the firefox binary that includes my changes, but excludes the commit range above, use it for a day or two and see if it happens with my patches as well. I'll do that in the meantime.

I'm seeing this same issue, trying to visit the front page of Twitter and Reddit.

We should figure out if this is Fission related or not. It is a pretty bad regression.

Probably same underlying issue as bug 1662925.

Based on our current understanding of the underlying causes of bug 1662925, this is likely that bug. Specifically, the bug triggers when attempting to queue a Fetch event to a process for which the PRemoteWorker actor has not yet been created. This will occur in cases where we opt to launch a new process because no process with the correct remoteType already exists.