1591942 - Run browser_mozprotocol.js test with Fission enabled

Status: RESOLVED WORKSFORME

(Firefox :: General, task, P3)

Description

[Mike Conley (:mconley) (:⚙️)]

With Fission enabled, browsing to moz://a in the URL bar results in an infinite process flipping loop.

It's supposed to redirect us to the Manifesto: https://searchfox.org/mozilla-central/rev/74cc0f4dce444fe0757e2a6b8307d19e4d0e0212/toolkit/components/mozprotocol/MozProtocolHandler.jsm#17 - or to the Mozilla Canada community page if using moz://eh.

Once this is fixed, we should be able to get browser_mozprotocol.js working with Fission enabled.

Comment 1

[Mike Conley (:mconley) (:⚙️)]

Hey Neha, I filed this bug so we could hook up something to row 620 of the Fission Mochitest tracking spreadsheet, but I'm relatively certain this is not an M4 thing we need to fix - we've got more important fish to fry than an easter egg. Should I go ahead and put this in M5 or Future?

Comment 2

[Neha Kochar [:neha]]

Mike, this seems to be getting fixed in https://bugzilla.mozilla.org/show_bug.cgi?id=1588412#c3 .

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Oooh, amazing! Thanks. :)

Comment 4

[Matt Woodrow (:mattwoodrow)]

I don't think bug 1588412 will fix this unfortunately.

I haven't debugged this fully, but if we're getting into a process switching loop, then I suspect that we're trying to make the process decision in multiple places, and coming up with different results.

I think what's happening that is DocumentChannelParent is calling into http-on-may-change process, which picks a process to use, and gets the 'real' URI from the actual channel (which I think will be the resolved http manifesto UR).

Then we setup a new process/docshell, and attempt to load there and then hit this process check - https://searchfox.org/mozilla-central/rev/3300072e993ae05d50d5c63d815260367eaf9179/docshell/base/nsDocShell.cpp#9253

That one is just using the URI from the DocShellLoadState, and could likely be the moz:// one. I suspect that'll then come up with a different answer, and we'll attempt to restart the load in a different process.

The long term fix is to get rid of the old process switching checks, and only ever use DocumentChannelParent. In the short term, maybe we could check for aLoadState->GetPendingRedirectedChannel() to detect when the current load is one that has been switched to us, and not check again.

Comment 5

[Neha Kochar [:neha]]

NI'ing Matt for his thoughts on this too.

Comment 6

[Chris Peterson [:cpeterson]]

Mike, Kashav unskipped this browser_mozprotocol.js test in bug 1653674 last year:

https://hg.mozilla.org/mozilla-central/diff/2a45b71b719fe9ceaf1348a736237caa6a1b7ee0/toolkit/components/mozprotocol/tests/browser.ini

Can we resolve this bug as fixed? Or is there additional work needed to enable this browser_mozprotocol.js test with Fission?

Comment 7

[Mike Conley (:mconley) (:⚙️)]

Yeah, I think so - it looks like the moz:// protocol works properly with Fission enabled, so something along the line fixed it. Closing this as WFM.