STR:

0. enable fission, restart
1. disable keyword.enabled in about:config
2. open new tab, put "idontexist:foo" in the URL bar, hit enter

ER:
A network error page loads ("The address wasn't understood") and the tab shows the warning triangle icon and title.

AR:
the tab updates immediately, but the content stays blank. Only mouseover/mouseout or other interactions seem to "trip" us into painting.

Because the tab updates immediately, I'm fairly sure that we load the page immediately/correctly - but something's wonky with painting. I'm just not sure what or how to debug it. Tested on macOS on a recent (last few days) m-c build, in case that matters.

Matt, Nika suggested you might know what's going on here?

Tentatively moving all bugs whose summaries mention "Fission" (or other Fission-related keywords) but are not assigned to a Fission Milestone to the "?" triage milestone.

This will generate a lot of bugmail, so you can filter your bugmail for the following UUID and delete them en masse:

0ee3c76a-bc79-4eb2-8d12-05dc0b68e732

I think this may be the same issue as bug 1580527. Gijs, can you check if this is still a problem?

I still see this on today's nightly with the steps from comment #0.

I can reproduce an issue, but not quite as described.

I can't get any error page at all to show up with 'idontexist:foo' + fission, regardless of mouseover/mouseout etc.

Gijs, is it possible that this is what you're seeing now?

Oh, mach run --enable-fission doesn't actually enable fission. The previous comment is what I see without Fission.

With fission actually enabled, I see the same as bug 1597154, endless process switches (since idontexist isn't a known protocol).

(In reply to Matt Woodrow (:mattwoodrow) from comment #5)

Oh, mach run --enable-fission doesn't actually enable fission. The previous comment is what I see without Fission.

With fission actually enabled, I see the same as bug 1597154, endless process switches (since idontexist isn't a known protocol).

Sounds like you managed to reproduce something, at least. :-)

Between comment #0 and comment #4 it sounds like this may have regressed for non-fission? I'll see if I can confirm that and if so get a regression window, leaving ni for that.

Tracking for Fission dogfooding (M5)

blocked by content process infinite loop bug 1597154

The non-fission behaviour was regressed by https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=95e0180f6a40275d54ae910a68c46f61e22b6854&tochange=94663676950dbdef63afb4d134b8add076a70b0b ie bug 1598516.

Matt, do you want to just fix the fission and non-fission case in the same bug, or do you want me to file a separate regression bug for the non-fission case?

Ok, I have a fix for the non-fission case, which I'll put here for now (since it affects both).

I tested with a super-quick hack for bug 1597154, and it now works in both configurations.

Before DocumentChannel, unknown protocol errors happened when we tried to create the channel, so didn't go through this path. With DocumentChannel we don't find out until we're in the parent process, so they come through as a failed request value, which encounters these filters.

Depends on D56841

Bugbug thinks this bug is a regression, but please revert this change in case of error.

https://hg.mozilla.org/mozilla-central/rev/ec0c794588d4

I encountered the same results while trying to reproduce/verify this bug, on both cases the page keeps loading and spins without stopping.
Not sure how could I verify this bug since I see no difference between the 2 builds.
Any other tips on how should I verify this bug?

(In reply to Hani Yacoub from comment #14)

I encountered the same results while trying to reproduce/verify this bug, on both cases the page keeps loading and spins without stopping.
Not sure how could I verify this bug since I see no difference between the 2 builds.
Any other tips on how should I verify this bug?

FWIW, I can confirm this - even when using mozregression --launch 2019-12-17 --pref fission.autostart:true to try the nightly immediately after this fix landed, I still see similar behaviour to comment #0 - the tab never paints, though now the tab icon also stays on the spinner forever.

The endless loading is bug 1597154, should be fixed soon.